Like most students studying engineering in the 90s, spreadsheets were the de facto calculation tool.  I used them for everything from food budgeting to pump and piping sizing calculations. 

Computing power has since exploded, and engineers have far better choices.  But engineers still continue using spreadsheets. 

Why?

There’s really only one reason – ubiquity and familiarity.  A spreadsheet is installed on nearly all desktop computers, but even though most engineers are aware of at least some of their design deficiencies they keep on using them.

Everyone’s familiar with the spaghetti logic that infests many engineering spreadsheets.  It’s difficult to follow the logic or flow of a calculation in a spreadsheet; the equations are hidden and written in an obtuse command-line notation.

Here are a couple of other spreadsheet problems that I’ve encountered on a semi-regular basis in my career supporting engineers in using calculation software.  These are real problems from the coal-face, and have caused headaches, furrowed brows, and a spike in stress and blood-caffeine levels.

The first problem arose when I was helping a customer debug an error-handling routine in a spreadsheet.  I’ve reproduce the essence of the error below, but bear in mind that this was buried deep within other calculations.

In both the following calculations, we’re essentially dividing a number by zero.  Only one variant gives the appropriate error message.  The other doesn’t due to floating point error (read http://support.microsoft.com/kb/78113 for more information.)  The error-handling routine in the spreadsheet only caught the divide-by-zero error, but not the floating-point error. 

The second problem was due to the precedence of operators in your favourite big-name spreadsheet.  Again, I’ve reproduced the source of the error below, but once more, remember that this was in the middle of a series of other calculations. 

 In essence, exponentiation binds more tightly than unary negation within the spreadsheet cell, but it’s the other way around in the macro environment (and in almost every other software tool).  My jaw dropped when I learnt that as well.

With the rapid increase in computing power over the last ten years, I’m surprised at why engineers still contort and bend spreadsheets to uses they were never designed for.  There are far better tools available, offering a far better environment for engineers to work in.  At Maplesoft, we’ve made a concerted effort to understand how engineers work and the tools they need.  The diagram below, for example, maps a (by no means comprehensive) list of Maple features onto the engineering problem solving process.

 The time is right for engineers to stop using tools that were never design with their needs in mind.  Tools, like Maple and MapleSim, support the engineering project lifecycle from automated model development to engineering analysis and producing final deliverables.

Of course, this potential means that the brightest times in this company’s history are still ahead of us.