← Back to context

Comment by cfiggers

1 day ago

Programmers pervasively underestimate the sheer amount of manual brunt work that business users routinely do by hand and with their own eyes, mouse, and keyboard to make spreadsheet-based processes "work out."

I work in Finance. It's routine for the folks I work adjacent to to spend literal hours performing a task using a spreadsheet. The same logic could be executed by a query engine or scripting language in seconds. But... I know from trying... it would take months if not years to accurately identify and account for all the weird exceptions and edge cases that the human operator is accounting for intuitively because of their undocumented tacit knowledge of the domain.

So while the spreadsheet itself as an artifact is a mess, and the process as a whole is gallingly inefficient... the outputs they produce are often preternaturally correct.

I mostly agree. There are certain classes of tasks where the spreadsheet is more efficient. It's "more efficient" because it 1) requires less set up time (like you said, translating a computation in a more traditional system could take months), but also because 2) the spreadsheet is a highly interactive and accessible environment.

We have a programmer on our team who keeps trying to convert our excel calculations to more structured systems (database store). The issue is that the spreadsheet-work almost always requires navigating and making decisions based on unstructured data. The format isn't formally specified, so in the end our programmer makes more mistakes because he doesn't engage with the data - the processing gets treated as a routine algorithm, and it's not. The interactivity (and the fact that we're not spending energy on formal specification) is what allows us to more effectively engage with the data.

Another important point is that spreadsheets more easily allows you to consider data points individually without hand cuffing yourself to one kind of processing algorithm or software design. I can easily edit one cell to make a correction in a data set (which is a double-edged sword). The programmer has to create an additional handler to handle the exception. Depending on the design/quality of the code, this could just be adding undesirable complexity in the software. So we can either spend 30 seconds and edit a cell, or spend half an hour adding to code (which by the way may never get used again).