At a recent user group meeting an attendee Chris discussed a problem he was having with the current project he was on, essentially he was being asked to fit 500 days of work into 300 days, a tough but common situation indeed. Chris had suggested all the usual things like cutting scope, extending the deadline, getting more resources, buying a competitors product and a few other creative suggestions, all of which were met with a “No, we wont do that.”. A few of us laughed and said welcome to the ‘Bring me a rock‘ game. Of course we had a lot of empathy for Chris since this situation is one most of us have been in at one time or another. We discussed his options, but could only see one - to diplomatically say “Here’s what we can achieve in the time” while looking for another job.
The software industry is still very young when compared to other industries and in general there are many facts about our industry that are not known or glossed over because at times some people don’t want to acknowledge the cold hard facts. Knowing these facts can help you in the “Bring me a rock’ situation and other situations by providing some independent backing for your position. So what are these facts?
Robert L. Glass has distilled 55 facts and some fallacies of software engineering into his book “Facts and Fallacies of Software Engineering” which is an interesting and easy read, with a lot of “Oh My God” moments. Knowing these facts and fallacies could help you avoid some of the perils of software development, like that experienced by Chris. Here are a random 10 facts from the book:
The most important factor in software work is not the tools and techniques used by programmers, but rather the quality of the programmers themselves.
Most software estimates are made either by upper management or by marketing, not by the people who will build the software or their managers. Estimation is, therefore, done by the wrong people.
Since estimates are so faulty, there is little reason to be concerned when software projects do not meet estimated targets. But everyone is concerned anyway.
Modification of reused code is particularly error-prone. If more than 20 to 25 percent of a component is to be revised, it is more efficient and effective to write it from scratch.
For every 25 percent increase in problem complexity, there is a 100 percent increase in complexity of the software solution. That’s not a condition to try to change (even though reducing complexity is always a desirable thing to do); that’s just the way it is.
Eighty percent of software work is intellectual. A fair amount of it is creative. Little of it is clerical.
Requirements errors are the most expensive to fix when found during production but the cheapest to fix early in development.
Missing requirements are the hardest requirements errors to correct.
Peer reviews are both technical and sociological. Paying attention to one without the other is a recipe for disaster.
Quality is not user satisfaction, meeting requirements, meeting cost and schedule targets, or reliability.
In case you are wondering how it turned out for Chris, well he stuck to his guns and said he could not make 500 days of work happen in 300 and was sacked. My guess is he ran out of rocks. I admire Chris for telling it how it is and sticking by it, but I wonder if next time he will stretch the truth because that keeps him in a job.