Over the last few months I’ve dabbled in building in doing my accounts using a spreadsheet (Google Sheets and Excel). The similarities are so stark that I wonder if this isn’t a new trend in managing accounts. If so, it is a dark path.
Both tools have integrated some functional characteristics. For example, they both update automatically to reflect changes in values. This is a good thing, in general.
My problem is that both tools have doubled down on automation. Both seem to be intent on forcing me to write references to every needed cell in the spreadsheet!
Now I don’t want you to think that I’m opposed to automation. I’m not. I use pen and paper, I use tools. I have a slight preference for pen and paper, but I'm using a spreadsheet too.
It’s not the fact that spreadsheets automate that has me concerned. Rather, it is the depth.
Previously, I'd created tables in Word. I can structure it so that it's correct; but I can also violate many of the "rules" whenever I need or want to. Word underlines some bits in green/red and throws up a few roadblocks; but not so many as to be obstructionist.
Google Sheets and Excel, on the other hand, are completely inflexible when it comes to their rules. For example, in Google Sheets if I sum up a column then by God every thing in that column and all the dependent references have to be adorned by being a "number". There is no way, in this tool, to silently ignore me mistaking a string for a number!
Now, perhaps you think this is a good thing. Perhaps you think that there have been a lot of bugs in systems that have resulted from un-coerced numbers. Perhaps you think that that if you aren’t escorted, step by step, through the dependent cells it would be risky and error prone. And, of course, you would be right about that.
The question is: Whose job is it to manage the "numbers". The tool? Or the pen and paper?
These so called "spreadsheets" are like the little Dutch boy sticking his fingers in the dike. Every time there’s a new kind of bug, we add a feature to prevent that kind of bug. And so these tools accumulate more and more fingers in holes in dikes. The problem is, eventually you run out of fingers and toes!
This is the wrong path!
Ask yourself why we are trying to plug defects with tools. The answer ought to be obvious. We are trying to plug these defects because these defects happen too often.
Now, ask yourself why these defects happen too often. If your answer is that our tools don’t prevent them, then I strongly suggest that you quit your job and never think about use a spreadsheet again; because errors are never the fault of our tools. Defects are the fault of users. It is users who create defects – not spreadsheets.
And what is it that programmers are supposed to do to prevent defects? I’ll give you one guess. Here are some hints. It’s a verb. It starts with a “T”. Yeah. You got it.TEST!
You test every number is indeed a number. You test that your formulas refer to actual elements; not empty cells. You test that you've recalculated everything!
Why are these spreadsheets adopting all these features?
We now have spreadsheets that force us to adorn every function, all the way up the dependent cells, with
number. We now have spreadsheets that are so constraining, and so over-specified, that you have to specify all the elements that they refer to!
All these constraints, that these spreadsheets are imposing, presume that the user has perfect knowledge of the system; before the system is written. They presume that you know which number is a number. They presume you know to not to mix different units. They presume you know which input should link to which output. They presume you know what units a result will come back in.
And because of all this presumption, they punish you when you are wrong.
And how do you avoid being punished? There are two ways. One that works; and one that doesn’t. The one that doesn’t work is to design everything up front before starting. The one that does avoid the punishment is to override all the safeties.
And so, you write everything on paper and you leave these so called "spreadsheets" alone.
Why did the nuclear plant at Chernobyl catch fire, melt down, destroy a small city, and leave a large area uninhabitable? They overrode all the safeties. So don’t depend on safeties to prevent catastrophes. Instead, you’d better get used to writing lots and lots of tests, no matter what spreadsheet you are using!
--
Of course, this is just early morning unfunny parody of an article by Bob Martin, The Dark Path.
I strong disagree with the sentiment expressed in the article. Types are a tool that help you write code safely. Tests are a tool that help you write code safely. Neither replaces the other.
To suggest that we should abandon static-typing is wrong. If I change something returning type A to returning type B I can see how that might mean I have to change a lot of my code base. That doesn't mean static typing is bad, it could mean anything!
- Maybe the design sucks, why does so much of the code know about type A?
- Maybe it's a good thing - you didn't know everything upfront, an assumption has changed, so you should change the code?
- Maybe you want to experiment? We should find a way to defer type errors to runtime?
- Maybe we should invest in tooling to make this problem more tractable? (Jackpot!?)
We, as software engineers, should be actively looking to advance the state of the art. We should be building tools to support our ways of working, not rallying against those that do.