What can we learn from our love-hate relationship with Excel?
Many businesses run on Excel. They use Excel to record and process all sorts of business information, not just financial information, but customers, products and plans as well.
Excel is in many ways a superb tool, but IT departments often criticize its over-use. There is no control over critical business information. It is not a multi-user tool. There is no separation between code and data, which makes maintenance and change control a nightmare. IT departments hate having to pick up support for users' spreadsheets because they are impossible to support properly.
Given our love-hate relationship with Excel (and other spreadsheets), it is worth examining why it is so popular.
The basic idea, of arranging data and calculations on a grid, is easy to understand. It is, however, a very artificial metaphor, not empathetic and human-centric in the way that, say, a video game is.
Excel is very flexible. There are lots of ways of manipulating, formatting and visualising data. However, there are serious limitations to Excel. You can not escape the grid metaphor. It is difficult to represent relationships between data, and many data structures such as hierarchies are impossible. It is hard to build reliable interfaces to other systems.
Perhaps a better word for Excel is that it is versatile. It can be put to many uses. As well as being a visual super-calculator, it can be used as a database or to apply business rules. Although it has limitations, it can deliver a wide range of useful solutions quickly without specialist assistance.
What makes Excel so versatile? It is not the grid metaphor, or its flexibility. Here are some ideas:
These are necessary qualities, but not sufficient. The thing that really makes Excel versatile is one of the things we criticise it for: Excel does not separate code from data.
In Excel, you build a solution around real data. This is very different from traditional application development, which abstracts the data into a design, and then embodies that in code to be installed. Building a solution in the particular case, rather than in the general case, is what makes Excel usable by non-developers.
This capability, of building solutions in the particular around real data, could be usefully added to many other systems. I imagine a user-maintained environment, rather like a wiki, which allows users to embed data and functionality in whatever structure and around whatever processes they need, while still delivering controlled applications where these are needed.
I am sure this is possible, and not that technically challenging. The hard part for us is to overcome our IT bias, and let users build their own solutions.