Estimates are a tricky thing. Ultimately, I don't think they work in software. We should be looking for a different solution. Think of it this way - a physic

Estimates are a tricky thing. Ultimately, I don't think they work in software. We should be looking for a different solution. Think of it this way - a physician can prescribe a medication and tell you how long you'll be on it, but can she estimate how long it will take before your blood pressure falls within normal parameters? She can tell you what has happened in the past, but suppose you take the medication and your blood pressure remains stubbornly high. Has she failed to meet her targets? A lawyer may be able to tell you, roughly, how long litigation tends to take, but can your lawyer estimate how long a case will take, what it will cost, what the outcome will be, and the date it will all be wrapped up? If that doesn't happen, did the lawyer fail to meet targets? Well, in both cases, sort of, yeah. You didn't get the outcome you wanted. But these professions, run by the people who staff them, understand what can be predicted and what can't. This blog entry uses the task of estimating painting a room as an example, and focuses on breaking the task into subsections. Ultimately, I think the entire approach is deeply flawed, and it all starts by thinking that software development is similar to something like painting a room, just a more complicated version of it. In my opinion, it's very different. Of course, it's very different from prescribing medication or litigating as well - in fact, I'd say that it's generally considerably less predictable than even these things. I'd say it's closer to writing a novel, creating a film, or recording an album, except that software needs to work, and can be much more mundane at times as well. Ultimately, I don't think the analogies are useful, we need to realize that software is its own thing, and steer clear of too much reasoning by analogy or example. Unfortunately, the anxiety caused by making estimates under conditions of uncertainty (and possibly duress) is a source of stress and unhappiness for developers, and I do think it's one of the things that drives people out of the field. I actually think this may also be one of the reasons people love creating apps as a hobby but hate doing it for money.