What are Water Breathers? by Bruce Nielson
In Robert Glass' excellent book, Fact and Fallacies of Software Engineering, one of his “facts” (I.e. Qualified opinions) if that “Most software estimates are preformed at the beginning of the life cycle... before the requirements are defined and thus before the problem is understood.”
He goes on to say that, unlike many of his “facts” in the book, there seems to be no controversy on this one; there seems to be general intellectual agreement that we lock in on estimates too soon. This being the case, he says, “Someone should be crying out to change things. But no one is.”
He then adds:
At the very least, you need to know what problem you are to solve. But the first phase of the life cycle, the very beginning of the project, is about requirements determination. ... Put more succinctly, requirements determination is about figuring out what problem is to be solved. How can you possibly estimate solution time and cost if you don't yet know what problem you are going to be solving?
Why No Outcry?
While I agree the basic sentiment behind what Glass is saying, namely that we do lock in on estimates far too soon, I can't help but feel that Glass has missed several important points. In future posts, I'll contrast the approach Glass is advocating to my own approach to software estimation and demonstrate that Glass is actually misunderstanding certain critical points about software development and estimation. He’s also confusing the subjective nature of a so-called “problem space.”
But at the moment, I want to look at a different aspect of this paradox that Glass is uncovering: if everyone agrees software estimates are locked in too soon, why isn't there a general out cry for change?
Glass holds this lack of outcry up as something strange to behold. Why would we all, time and again, slit our own throats like this? Surely we're smart enough to change blatantly stupid behavior like this!
Human Psychology and Software
In my opinion, Glass has fallen into the trap of overlooking the overriding importance of human psychology as it pertains to software solutions. The problem of “premature software estimations” can't be fixed by simply pointing out that the estimates will be bad at that point and failing to address the real problem.
Glass has failed to realize that upfront software estimates are what I call a “water breather.”
Imagine that you angered the mafia. The Godfather has you caught, puts you in cement boots and drops you into the Brooklyn river. There you are, holding your breath at the bottom of the river. You are starting to pass out. This is it, you're going to die.
Why not go ahead and see if maybe you can breathe water?
Sure, normally trying to breath water is a bad idea and I don't recommend it. But if you are in the situation above, you really might as well. You're dead anyway and there has got to be at least some very (very very) slight chance that you happen to have a genetic adaption that you didn't know about until this point whereby you can breathe underwater. Since the risk of death by drowning yourself has been eliminated, it really is time to try to breathe water. Go for it.
Of course you're probably not genetically adapted for water breathing and you're probably going to die. But you were definitely going to die if you didn't try, so what the heck.
As silly as this example seems, its actually quite logical. And it explains quite accurately the real reason we lock in on premature software estimates over and over again despite overwhelming evidence that they don't work.
Business Plans Are Part of Reality
What I am trying to say, is that Glass is ignoring all together the very real need – overriding need – to make business plans. Once we factor in this overriding need, upfront software estimates make perfect sense. Sure, they don't statically work. But if you're only other alternative is to never do the project in the first place – and I contend that is almost always the case – of course you're going to make an upfront estimate and go for it. Why? Because it's the single most sensible thing for you to do under that circumstance.
And actually, this is better than water breathing. In water breathing, testing your genetic adaption to breath water only buys you another faction of a second at the most. But when it comes to upfront software estimates, making a bad estimate buys you months or even years to come up with good reasons why the estimate was “right, except things changed” and convince everyone (often including yourself) that you need a “minor” change of plans or maybe a “follow on project.”
In short, “premature software estimates” are here to stay because they make rational sense compared to the next best alternative. People innately “get it” and do what is in their and often their company’s best interest: they go ahead and make the premature estimate and roll the dice and then start working on their best excuses. I just can't argue with this logic and I certainly wouldn't want to see it changed or “fixed” until we really do have a better alternative available.