Trying to bring ideas and technology together into something useful and / or beautiful can be quite similar to the Zen koan of the Unstoppable Force and the Immovable Object. On one side of the spectrum we have the pure techie. In the technician’s world neither the unstoppable force or immovable object actually exist; physics doesn’t cater for metaphysical analogies which won’t obey the principle of conservation of energy. Everything can be modelled to an acceptable precision, implemented, and tested under labratory conditions.

Situated across the vastness of space from this position looking slightly puzzled by the entire affair is the user. To this paradigm of luddism, anything is possible. If Johnny Five can control a signboard with his anodized remote-control proboscis gizmo, then surely you can write me an application that can enable me to talk to the dead? “Sandra Bullock can hack computers, I saw it on some documentary about the information superhighway…can we get her in to give some training?”.

Populating the vast and nebulous void between these two crude, hyperbolic stereotypes we find everyone else. Some of us will tend more towards one pole or the other (in general the distribution for people involved in engineering is probably skewed in the direction of the techie). This middle ground finds itself adopting the position of interpreter between these two factions, converting “wants” and “needs” into tangible actions that will eventually result in someone spewing out a few thousand lines of code. The process of translating the needs of the user into something which is actually possible for an engineer, let alone practical or useful is known as “gathering requirements”.

Requirements capture and task estimation are among the most critical and neglected areas in software development. Jamis Buck wrote a very interesting take on how task estimations tie in closely with the assumptions made about the necessary requirements. Each side of the argument have their flaws; developers often “gold plate” projects in order to learn new technology or processes, users add in cool-sounding ideas which have no real business value and add complexity and overhead to the development process.

“Facts and Fallacies of Software Engineering” by Robert L. Glass is not devoted to estimation or requirements capture; rather it is a collection of observations about the process of engineering software, covering design, implementation, testing, and management that the author has found to be true in his decades of experience. That there are a disproportionate number of points which are either entirely devoted to, or touch on the subjects of requirements capture and estimation make this book required reading.

The author has assembled fifty five concepts he has observed throughout his career as a developer, researcher, and technology writer. To the experienced engineer there is nothing covered which should shock or provoke controversy; rather it is a refreshing reminder of the pitfalls that most projects will encounter in some form or other. In relation to the issues described above I offer these two supporting points:

• Point 9 – One of the two most common causes of runaway projcts is poor estimation
• Point 23 – One of the two most common causes of runaway projects is unstable requirements.

Other points of interest:

• Point 2: The best programmers are up to twenty eight times better then the worst. – This interesting statistic could be quite worrying for the management of project teams, or it could be an economic confidence booster. An engineer that is 28 times “better” then his peers is obviously a bargain (Unless you’re paying them twenty eight times more). But if none of your engineers are more productive then the others, do you have a team entirely consisting of alpha-engineers or a team full of dummies?
• Point 28: Design is a complex, iterative process. Initial design solutions are usually wrong and certainly not optimal. – This would, upon first inspection, appear to be a win for the agile software development practicioners in favor of the waterfall advocates. My interpretation of this point is that a hybrid combination of a sturdy initial design, coupled with the flexible approach of agile development will serve you better then relying too heavily on one approach to the detriment of another.
• Point 21: For every 25% increase in problem complexity, there is a 100% increase in software complexity. – I think that this is one of the strongest bargaining points to use when considering whether to add a new requirement or not. The new requirement might sound amazing, and it might be an interesting challenge, but will it kick your project estimates into orbit?

The author has freely admitted that the “fifty five” is an entirely arbitrary enumeration, with the added bonus that it adds a tongue-twisting alliteration to the book’s original title (Fifty five fascinating facts and fallacies of software engineering). The ten fallacies tacked on to the end are more of a wake-up call to the Dilbert school of management – in particular, a fallacy on using lines-of-code as any sort of performance measurement was something I thought was a relic of past ignorance until I had a conversation with someone who was recently berated by his employer for only producing a meagre handful of code in a given period. The fact that it was an extremely complicated bugfix which required hours of probing into murky old code, and that it resulted in a huge system improvement does not fit into such a narrow metric.

This book should not teach the experienced engineer anything new, but the sharp staccato format will reinforce experential knowledge – in particular the thought and precision which must be devoted to nailing down requirements and reigning in the estimation process. For any aspiring engineer, this book is gold dust.