The problem with back of the envelope calculations

Dale Humby bio photo By Dale Humby
Today I tasked one of my engineers to do a quick and dirty calculation to specify the size of a capacitor before we built a prototype circuit. However, I think I learnt more as a manager specifying a task than we did as engineers from doing the actual calculation. We want to decrease the load on a transformer by smoothing out the current draw for a circuit that has low average current but high peak currents every few milliseconds. The calc can be found in just about any first year physics textbook.

After a few minutes banging away on a calculator, "The capacitor," I was told, "needs to be about the size of a small hand-bag dog."

How had things gone so far off target in such a short amount of time? Conservatism.

Sure, we didn't know the exact profile of current usage for all circumstances that the electronics would be subjected to - but that wasn't the point of this calculation. All I wanted was a good first guess so we could at least build a circuit. Instead, I got an answer that was about three orders of magnitude over-spec'ed.

For each term in the calculation the engineer had doubled or tripled the realistic value, thinking that he was being prudent, happy bathing in his conservatism.

All that doubling and tripling soon multiplied together to give a figure that was 1000 times larger than a realistic guess of the numbers would have given.

My thinking is that 'back of the envelope' style calculations have no place for safety factors. We are not trying to design something, just get a feel for what it might be.

As a business owner I should have pulled the plug on the project, deemed the idea 'infeasible,' shook my head sadly and say that that technology wasn't yet where we needed it. And we would have lost a potential revenue stream. All because we were being conservative too early in the development process.

The early stages of product development should be about exploring ideas and testing solutions as quickly and cheaply as possible. Brainstorming comes up with problems and solutions faster than calcs; back of the envelope calcs are faster than prototyping, prototyping is faster than detailed design. And the big bonus of prototyping and testing is that you get to collect real data and test your assumptions quickly. This allows you to expand on your model for the next iteration through the design cycle. And at each stage you narrow the possibilities by discarding solutions that don't work, quickly converging on the final, now obvious solution. All backed up by empirical data.

All because we don't want to be conservative too soon.