Well, there’s a question: what is a Spreadsheet Engineer, as opposed to a Spreadsheet Developer?
We’ve already skirted around this in my previous article about Spreadsheets and Risk. Since nearly everyone can ‘develop’ a spreadsheet model by entering some data and saving the file we can extend the idea of ‘Spreadsheet Developer’ to anyone in your business who is using a spreadsheet package and creating their own spreadsheets. And make no mistake, there’s a definite risk involved in this, most often not even recognised.
The problem is that few of these spreadsheets have been developed with the use of any methodology or testing. In fact, it’s quite unlikely that their creator can guarantee flexibility, structure or transparency within these models. Worse, they often can’t guarantee accuracy as this is frequently not even tested. Always assuming that the developer is actually still working in your business, of course.
To help frame what is going on with this most common sort of spreadsheet development, I’m going to borrow a line from Weinberg [“The Psychology of Computer Programming” , 1998]:
The amateur, then, is learning about his problem, and any learning about programming he does may be a nice frill or may be a nasty impediment to him.
So we have people creating spreadsheets, often from scratch*, and usually to solve the problem currently taking up space on their desk (or desktop). From this it becomes quite clear that to minimise risk to your business, and to improve upon these often haphazard models, we need both something and someone else.
From Weinberg again:
The professional, conversely, is learning about his profession—programming—and the problem being programmed is only one incidental step in his process of development.
Or, to extrapolate, you don’t need a Spreadsheet Developer, you need a Spreadsheet Engineer.
Spreadsheet Engineering is a phrase coined by Professor Thomas A. Grossman of the University of San Francisco, which adopts, then adapts, the lessons of other software engineering to spreadsheets. Spreadsheet Engineering provides eight principles as a framework for organising spreadsheet programming recommendations:
1: Best practices can have a large impact
2: Lifecycle Planning is important
3: A priori requirements specification is beneficial
4: Predicting future use is important
5: Design matters
6: Best practices are situation-dependent
7: Programming is a social, not an individual activity
8: Deployment of best practices is difficult and consumes resources
If you’re following these principles it means that now you are not simply a creator or developer of spreadsheets, but that you’re a Spreadsheet Engineer. For you this is a discipline and not just an ad-hoc piece of work to get your boss off your back.
The Final Word
Congratulations if that’s you. Congratulations if that’s who you have working for you. If (most unfortunately) neither of these cases apply, then both you and your business are running a risk, perhaps a considerable one and perhaps unknowingly.
In case you are wondering, I am a Spreadsheet Engineer: you should talk to me.
* User creates spreadsheets from scratch each time (data taken from SERP survey)
36.3% – Always;
62.1% – Often;
1.5% – Never.