Surely the title of this post will surprise more than one person. Delete the Excel spreadsheet? If we did, probably 80% of companies would be paralyzed. They simply couldn’t function.
If this, in itself, doesn’t seem like a reason to suggest that we’re doing something wrong, let me clarify. You should delete Excel right now. Eliminate it, zap!, deleted forever.
Before the hordes of Excel fanatics come after me, waving banners with slogans like “VLOOKUP() RULES” or “I ❤ OFFSET()”, I invite you to read the rest of the post and reflect on the use (and abuse) of Excel spreadsheets.
What’s wrong with the Excel spreadsheet?
In my professional experience, I have often had the opportunity to collaborate as a consultant to integrate systems and automate processes. As gratifying as this work is, as a result I have had to battle with Excel spreadsheets on more occasions than I could count, as well as with the staunch (and sometimes irrational) defense of their users.
Every time a user asks for my help, uttering a phrase that starts with “I have a shared Excel sheet that…” or “I have an Excel with a macro that…”, personally, I start to tremble.
Perhaps it’s professional deformation, but when faced with these inquiries, the first thing that comes to my mind is “You are not using the right tool”. You need something, something you might not even know you need (probably a database or software) that should cover that function for you.
Computer science or, more properly, information technology, is called that for a reason. It’s called that because it’s designed to manage vast amounts of information, process it, and deliver it to the user when and how they need it.
Computer science is not (or should not be) a user staring at an Excel sheet with thousands of rows, dozens of columns, a medley of tabs, some of them hidden with “sinister” calculations and data “chaotically arranged”.
I have seen ships on fire off the shoulder of Orion things you wouldn’t believe:
- I have seen companies perform their calculations (structures, installations, infrastructures…) in Excel.
- I have seen companies create budgets, manage orders, issue delivery notes with Excel.
- I have seen companies create, share, and store reports in Excel.
- I have seen project management with Excel, Kanban in Excel, Gantt charts in Excel.
- I have seen personnel control, absenteeism, clock-ins, and vacations managed in Excel.
- I have seen customer and supplier information stored in Excel.
- I have even seen companies base their accounting and strategic plan on Excel.
If you’ve read this far and I still haven’t managed to make your hair stand on end or, at least, make you consider that perhaps Excel isn’t as good an idea as it seemed, let’s list the 12 demons for which you should delete Excel in your company.
12 Reasons to Stop Using Excel
Abstraction
Making an Excel sheet is easy, you simply write according to your needs and configure a tool that is useful and to your liking.
But has the analysis of the entities that make up your model and the relationships between them been done correctly? Is a delivery note associated with a single order in a 1-1 relationship? Can an item belong to one product line or several?
With an Excel sheet, you skip the analysis of the entities that make up your data model, their properties, and the relationships between them, something fundamental to understanding how your business works.
Encapsulation
An Excel sheet is a simple table. Nothing prevents the user from accidentally writing in the wrong cell or from data getting mixed up when moving or copying data.
When you develop software, an entity is unique and its encapsulation and integrity are guaranteed. An order has its properties, and there is no possibility of it accidentally mixing up with the cost or rate of another order.
Efficiency
The speed of an Excel sheet is not even remotely close to the efficiency you can get with a development. Operations like searches across several thousand rows, which are prohibitive in Excel, are executed effortlessly in software.
SQL queries (which I recommend you avoid at all costs) deserve special mention. I have seen users who, out of ignorance and with the best intentions, mention having a query in Excel that takes 3 minutes to run. They associate, since it takes a long time, it must be a great query, how proud I am. Believe me, there’s nothing to boast about leaving a database hanging for 3 minutes. When you run the same query in 0.3 seconds, then you’ll have a reason to show off.
Data Management
Excel sheets can become huge, even more so with the latest expansions they have received. They can accommodate vast amounts of data. Well, even so, it’s nothing compared to what can be stored in a database.
Much more importantly, Excel sheets can host large amounts of data, but they are not capable of managing them properly. Searches are slow and are always critical because it’s easy to make mistakes and provide incorrect results.
In contrast, databases are specifically designed to be efficient when performing searches and cross-referencing data, and are extraordinarily more powerful in data management.
Workflows
Normally, in modern development, you want actions to be generated. For example, for the system to alert you if the stock of a material falls below the reorder point, or even to automatically place the replenishment order with one or more suppliers.
In an Excel sheet, you cannot perform any action. The system is passive, it doesn’t inform you or perform actions, you can only enter and fill in/consult the data.
In contrast, software development can contemplate any number of workflows regardless of complexity. This has the double advantage that, on the one hand, it forces you to define your processes, and on the other, it allows you to automate tasks. All of this is not possible in a spreadsheet.
Collaboration
Although there have been multiple attempts to improve the way of working on the same Excel sheet, and it is possible to share a sheet so that several users write simultaneously, the truth is that none of these solutions works adequately.
Sharing an Excel sheet, whether in a network folder or in online applications, forces us to eliminate many features that we have in a non-shared sheet.
In contrast, again, databases are specifically designed to allow multiple users to access simultaneously, this being their main function.
Public access deserves special mention, that is, providing, for example, limited web access to your customers so they can consult certain data. All of this is impossible with an Excel sheet.
User Interface
Again, an Excel sheet is nothing more than a table. No matter how much you add colors, change fonts, merge cells (please don’t merge cells), or paste images (another bad idea, by the way), add charts or pivot tables, it can never compare to the interface you can achieve with an App or a Web.
On the other hand, users are increasingly connecting via mobile devices. No matter how many clients exist to view Excel on these devices, they cannot compare to the viewing and user experience on a responsive Web.
Security
Understood as protection systems against the misuse of the contained information. This includes both accidental manipulation and conscious inappropriate use.
What are the consequences of someone accidentally modifying the formula for calculating the cross-section of the concrete pillars of a structure? And those of an angry employee saving the Excel file with which you perform electrical calculations on a USB drive? And the one where you store your customer information? Are you aware of the risk this poses to your company?
In software development, you define which users or groups of users access which information, and what actions each of them can perform. This security is not possible with an Excel sheet.
Maintainability
Maintaining Excel sheets is often difficult to do. Frequently, these sheets are created by people with high Excel knowledge and who, probably, at the time put in a lot of effort to create them. It is also common for the same person, months later, to be unable to modify their own tool or, even, for it to be used years after the person leaves the company.
Who assumes the maintenance of that Excel sheet? I certainly don’t if I can avoid it. I have found Excel files where, honestly, I didn’t dare to touch because they were “held together with pins.” In the end, I always end up replacing them with a well-made development.
In contrast, correctly done software development is designed so that any other developer can provide support and extend the code.
Sustainability
When tackling an Excel sheet, a sustainability horizon beyond a few months is rarely considered. What will happen to your huge Excel sheet in 2, 3, 5 years of operation? How much will it have grown? Will it be manipulable or will it be too large? Will you have many files, or everything in one? How will you maintain the data, will duplicates be created? And if you have to modify something, will you have to go to all the sheets to maintain them?
On the other hand, how will your Excel sheet behave when Microsoft changes versions? And when your workflow changes? Will you at least be able to recover the information easily to migrate it to another system?
Similar to maintainability, when tackling a development, it is considered that it should be extensible, modifiable, and able to be in operation for a prolonged time.
Professionalism
We could say that in a way it is the origin of all the previous points. As commendable (even endearing) as it may be for a person with initiative to make an effort to train themselves and try to cover their own needs, IT professionals exist for a reason.
The user does not have specific training in abstraction and encapsulation, is not used to managing data and workflows, does not take into account design factors like efficiency or maintainability. Concepts that are everyday for an IT professional.
Cost
It may seem that making an Excel sheet is quick. In opposition, doing a development has longer times and, therefore, higher costs. Nothing could be further from the truth.
It may be that, initially, it indeed seems faster to make a spreadsheet and “that’s it.” But what about the additional benefits of defining your work model and its associated processes? And the advantage of automating tasks? And the loss of time from using a tool that is not efficient and makes the user lose time every day? And the time for maintenance, expansion, and sustainability?
On the other hand, Excel technology, particularly integrated VBA (I tell you very seriously, I don’t know how anyone can still program in that) makes development times longer when macros or SQL queries are involved.
The tools available to develop an application, for example, in C# or HTML5, are light years ahead. Tasks that are trivial in modern programming, tackled in VBA force you to develop with 20-year-old technology, which lengthens deadlines (besides being unbearable).
Even assuming that the time required to make a quick Excel sheet, compared to equivalent software development, is less, the truth is that in the second case you have a product far superior in features, power, and versatility.
If you consider all associated costs, on balance, it’s cheaper to do a development. Believe me, the Excel sheet is costing you money.
Reflection and Self-Criticism
The Excel spreadsheet is a tough rival to beat. First, because its use is ingrained in the user. They feel they can personalize it, configure it to their liking. It’s simple, familiar to them, they feel comfortable using it.
The problem is not with the Excel spreadsheet, which, by the way, is a powerful and truly great program (come on, I finally admitted it, deep down I love it too). The problem is the use and abuse of Excel spreadsheets. As they say in the trade, when all you have is a hammer, everything starts to look like a nail.
On the other hand, as a developer, you will hardly get the user to stop using it if as a substitute you intend to give them a program whose user interface is basically a table (a grid). There, Excel will always beat you, because as a table you won’t be able to surpass the functions that Excel allows.
Recently, user interfaces have undergone a great improvement, largely due to the development of mobile and Web Apps. As a result, users have become intolerant of bad UIs. If you intend for your users to stop using Excel to use a program with a Windows 98 aesthetic, it will never work. You have to provide them with a far superior aesthetic and functions they won’t get in a simple spreadsheet.
But, oh friend!… That takes effort! And I’m not just talking about development time, it requires an analysis of the user’s needs, understanding their work model and their workflows, and proposing creative and modern solutions. In short, it requires you to do your job well and with “care”.
However, even recognizing that the spreadsheet is a powerful application, a tough rival, and, in certain occasions, a useful tool, if we analyze it deeply, spreadsheets really have no reason to exist (or shouldn’t have one in a “perfect” world).
Spreadsheets are, in short, programs that allow us to configure “small utilities” quickly. Every time someone uses an Excel sheet, it’s because a program (equivalently, a developer) has not provided them with what they need.
The Excel sheet is the resource you turn to when you don’t have “anything better.” Therefore, in a framework of continuous improvement, the Excel sheet will always be one of the weak links and, inevitably, will end up being eliminated.
Conclusion
Beyond quick calculations or making a couple of charts, we should not have the need to use Excel sheets. It can also be useful as a sketch, or first solution, of what will later become a specific development. In this way, the user themselves is doing part of the analysis and abstraction of the problem and participating in the solution.
But a spreadsheet should never be considered as a permanent solution. Much less as an optimal or desirable one. Certainly, under no circumstances should you base fundamental processes of your business system on Excel sheets.
If you do, sooner or later a competitor will emerge who does things properly. You will find a competitor with software superior to yours and, then, you will find yourself in serious trouble because you will be less competitive.
At this point, it’s worth mentioning a quote from the 2014 Barcelona Forum, by Jan Muehlfeit, President of Microsoft Europe.
“In three years all companies will be software companies, education must prepare for that” - Jan Muelhfeit (2014)
I totally agree with this statement. So much so that I allow myself to expand on it. Not only must education prepare, but companies must also do so.
Your competitor has machines similar to yours, has personnel similar to yours, has an economic and financial framework similar to yours. Your software and your workflow may be the only thing that gives you a competitive advantage.
If you don’t do it, if you don’t invest in development and let fundamental processes of your business model be based on spreadsheets, you not only risk it, but it is inevitable that you will end up being surpassed.
So now you know. Start considering the real virtue of Excel sheets and learn to always see them as a non-optimal option, 12 little demons that reduce your competitiveness, and a clear target to eliminate from your workflows.
