Excel formulae are a programming language, so we need to learn from our software development colleagues.
Software development went through a crisis in the 1970s to the 1990s, with high-profile delivery failures resulting from the difficulty of writing reliable computer programs within time and budget constraints.
Spreadsheet development has the same issues, but we have not learnt the same lessons.
Software engineering to the rescue
Software developers addressed their crisis by creating software engineering as a formal discipline. Software engineering "applies the engineering design process to design, develop, maintain, test, and evaluate computer software". Of course, developing software is still difficult and has many challenges, but it is much better than it was.
Meanwhile, spreadsheet users have largely not addressed our own development crisis, though we know it needs to be done:
As was the case of the software crisis and the eventual emergence of software engineering, the world will eventually realise that spreadsheets can be engineered to be safer and that the careful application of such techniques does not stifle the creativity and flexibility of spreadsheet modellers.
Thorne, Defending the future: An MSc module in End User Computing Risk Management
Consensus: Spreadsheets need good practice guidelines
The spreadsheet academic and practitioner literature presents a consensus about the need for spreadsheet good practice guidelines. However, there is little agreement, and even less formal research, about what those guidelines should be.
One approach is the development of formal spreadsheet standards – such as the "Flexible, Appropriate, Structured & Transparent" (FAST) Standard. The FAST Standard is a set of more than 100 rules that define what to do or not do when building a spreadsheet model. FAST is focussed on the domain of financial modelling – specifically modelling of large financial transactions. The standard is not widely applied, or even applicable, outside the financial domain.
In creating our guidelines, we have adopted a broader perspective. We don't define rules. Nor are we focussed on a specific domain. Instead, like our software development colleagues, we attempt to define general principles, and specific guidelines which are widely applicable.
We wouldn't accept other software built like we build spreadsheets. As spreadsheet developers, users, and managers we need to learn from our software development colleagues and adopt good practice guidelines to improve the way we build and manage our spreadsheets.
