Excel is the software development environment for the programming lay person. I don't mean that pejoratively; it does an incredibly good job. But introducing more rigor seems like it will mostly just reduce its effectiveness in that role.
I guess telling people "Here are some common spreadsheet oopsies" could be useful. However, I don't see a world where the most approachable and broadly used method to make software stops being rife with programming errors.
There has been extensive work done on categorising spreadsheet errors - see, for example, https://eusprig.org/research-info/research-and-best-practice.... A lot of this work was done over 2 decades ago. In my experience these is a lot less use of VBA macros compared to twenty years ago (taking out a large class of potential complexity and errors), but otherwise it appears that very little else has changed in that time with regards to critical spreadsheet errors. Most of the spreadsheets that I use are meant to be quick-and-dirty single uses, but a lot of the time they get copied and begin to take on a life of their own throughout an organisation - and that's where the errors creep in. It's easy to say that there should be a review process, and formalisation, of these spreadsheets before they get reused, but that fails to recognise that the reason these spreadsheets exist is that they solve an immediate business problem. There is rarely time for anything better. In my opinion, we should be training people that spreadsheet CAN, and are LIKELY TO, have errors, and that you shouldn't just accept 'the answer' popping out from a spreadsheet - we need to be skeptical of the use of the spreadsheets, and not be afraid of questioning them.
2 comments
[ 2.3 ms ] story [ 21.6 ms ] threadI guess telling people "Here are some common spreadsheet oopsies" could be useful. However, I don't see a world where the most approachable and broadly used method to make software stops being rife with programming errors.