Software Estimation

I feel being in the software industry is especially challenging because one has to do software estimations every now and then. Though I'm not sure if someone in a different industry has to do so frequent work/task estimations, but I assume not. If you are in a different industry and think you that's not the case, let me know. Having said that, I want to focus on the why of software estimations. But before we begin, let's see what people usually do. If you are a software programmer or tester, you'd know that your manager wants you do a software estimation first before actually going ahead with the development of testing process. If you are in a support project, your manager may also have asked you prepare an impact analysis along with the estimation sheet. So why do it?

Most of the time I've seen people abruptly telling their boss that a particular task can be achieved in n number of days/hours/months etc as soon as they are asked about the feasibility of the task. Later, they realize (either during development or a bug-fix or testing) that the estimation of n weeks/days/months is taking them nowhere and there is no way they will be able to achieve the task goals without over-running the cost and initial estimate. Well, if that's happened to you even once in your IT life, it's time you learn to keep your mouth shut when you are asked to do a feasibility study or estimation for a task. At least do not utter a word immediately or as soon as you're asked.Take your time, and then after you've given the task a good thought and researched about the feasibility, go ahead and do the estimates. But the question remains ... WHY DO THE ESTIMATIONS?
I am also skeptical about the whole enterprise of software estimation. At times I say to myself that we should never make schedule estimates. The managers should manage his developers by trying to get them excited enough about the features he thinks should be added to the product that they decide to go ahead and add them. Or they may get excited about their own ideas and add them instead. Manager should retain final authority over what gets added to the product and a developer who consistently gets excited about developing things that Manager refuses to allow into the product should probably make sure their resume is up to date. But he should never ask them for estimates. He should encourage his developers to spend most of their time working on things that they can finish quickly and get into the product, but that seems to be as much about, what one might think, most likely to keep his developers happy as anything else. When they need to, the developers will tackle bigger projects, still without estimating how long they will take. My point of view, and you will have to take it, is that the only reason to do these big projects is because you have to, and if you have to, it doesn’t really matter how long it’s going to take.

On the other hand, estimates are very much essential too. A good estimate is an estimate that provides a clear enough view of the project reality to allow the project leadership to make good decisions about how to control the project to hit its targets.

I think the key word in estimate's definition is “targets”. The reason one can get away with not estimating is because one has found a way to manage without setting targets. So the question “Why estimate?” is better expressed as “Why set targets?”

Sometimes we set targets in order to convince others, or ourselves, that something can be done. We may set targets to inspire ourselves to do more, though it’s not clear that’s a winning move, and even less so when managers set a target to “inspire” the folks who work for them. We may also set targets to give ourselves a feeling of control over the future, illusory though that feeling may be. After the fact, a target hit or missed can tell us whether or not we did what we set out to do. However if we missed a target, we can’t know whether that’s because the target was unrealistic or because we didn’t perform as well as we should have. Setting and hitting targets does make it look like we know what we’re doing but we need to keep in mind that targets rarely encompass all the things we care about — it’s much easier to set a target date for delivering software than a target for how much users will love it.

If the goal is simply to develop as much software as we can per unit time, estimates (and thus targets), may be a bad idea. Programmers are more productive when working against their own estimates as opposed to estimates created by their boss or even estimates created jointly with their boss. On projects where estimates are made by third-party system analysts the average productivity is usually higher. This last thing may be a bit of a surprise, ruling out the theory that programmers are more productive when trying to meet their own own estimates because they have more vested in them. But the real surprise is that the highest average productivity is on those projects that didn’t estimate at all.

There is, however, one other reason to estimate: to coordinate our work with others. In my earlier project, the marketing department would like the developers to estimate what features will be included in the next release/iteration so they can get to work writing promotional materials. Or one developer wants to know when a feature another developer is working on will be ready so he can plan his own work that depends on it. Note however, that in cases like this, estimates are really just a tool for communication. Marketing needs to know what’s going to end up in the release and the developers, by virtue of being the ones building it, have the information and somehow that information has to be communicated from the developers to the marketers. But there are lots of ways that could happen. In a small company it might happen for free — everyone knows what everyone else is working on so the marketers will have as good an idea as anyone what’s actually going to be ready for the release. If coffee machine conversations are insufficient, then marketing and development could meet to talk about it on a regular basis. Or the developers could maintain an internal wiki about what’s going on in development. Some of these methods may work better than others but it’s not a given that using estimates is always the best way.

To decide whether estimates are a good way to communicate, we need a way to compare different methods of communication. I’d argue that all methods of communication can be modeled, for our present purposes, with the following five parameters:

* Preparation time required
* Communication time required
* Rate at which information is conveyed
* Rate at which misinformation is conveyed
* Other benefits and costs

The idea is that communication happens in this pattern: one or more people spend some amount of time preparing to communicate. This would include activities such as thinking, writing, estimating, etc. Then the communication proper happens, which takes some time. This may require time from both the sender and the receiver (conversations, meetings, presentations, etc.) or only the receiver (reading an email, looking at a web site).

After the communication is complete, some amount of information has been conveyed and also, sadly, some amount of misinformation. The misinformation may arise from faulty preparation, from misstatements by the sender, or from misunderstandings by the receiver. Obviously different methods of communication will be able to convey more or less information in a given amount of time and will be more or less prone to miscommunication.

Finally, different methods of communication can have benefits beyond the information conveyed and costs other than the time spent and the misinformation conveyed. For instance, chatting around the coffee machine may build team cohesion while highly contentious meetings may have the opposite effect. Another important kind of benefit is that the preparation and communication phases may itself improve the communicators’ understanding of what they are communicating about. For example, writing clearly on any topic invariably forces the writer to clarify their own thoughts and the give and take in a well-run meeting can help bring out and refine what were previously only amorphous notions.

Now we can look at estimation as a communication tool according to this model. The preparation time for good estimates is fairly high. This is why so many developers try to avoid estimating or give it short shrift :). The communication time is low — since an estimate distills things to the essence of “these features by this date” or “this much effort for that much functionality” it can be quickly conveyed. However, exactly because estimates do distill things, they are a low bandwidth form of communication. Without a lot of other communication about what exactly the features are going to look like, a list of features and the dates when they will be done, leaves out a lot. Worse yet, estimates are notoriously prone to conveying misinformation, either because the estimate is inaccurate or because an accurate estimate is misunderstood. No presentation style can help the poor estimator who’s giving an estimate to an audience that hears “2 to 4 weeks” as “2 weeks” though :(

When it comes to other costs and benefits, it’s hard to say. If we assume for the sake of argument that it is possible to make good estimates, does the very act of preparing the estimate have its own benefits? Certainly, making a good estimate requires identifying all the work to be done, so a team that has gone through the exercise of estimating may identify all the work that actually needs to be done sooner than a team that hasn’t, which may allow the work to be done more efficiently. Another potential consideration is that in a company where non-developers expect developers to be able to provide reliable estimates, then meeting those expectations has the social benefit of giving the rest of the company confidence in their development team.

On the other hand, there’s no guarantee of obtaining those benefits. Estimating badly certainly has bad ancillary costs. Leaving aside the consequences in terms of the misinformation it generates, it’s just no fun to estimate when you know your estimates are bad :( Either you feel guilty because you believe it’s possible to do well and that you should be better at it or you think it’s actually impossible and therefore whoever is asking you for the estimate is wasting your time. And if good estimates can increase the company’s confidence in their developers, bad estimating can destroy it. Or, worse yet, developers can be unfairly deemed unreliable because the rest of the company expects more precision in estimation than is actually possible. At the beginning of a project even the best estimators can be up to 4x off in either direction. Which means unless folks can accept an initial estimate of “from three months to four years” and a promise to refine it over time, developers are bound to disappoint.

So we have: High preparation cost. Low communication costs. Low bandwidth with high potential for misinformation. Ambiguous ancillary costs and benefits. Clearly, if you’re going to estimate, you’d better do it well and accept the costs that entails. But if you doubt it’s possible to do well, either in principle, or in your particular situation, then it can be useful to think about other ways to make sure the necessary communication happens... Enough said for today ...
Let me know what you think why you should estimate and if you've ever estimated something that did not go too well on timelines ... :)

Some content also taken from http://www.gigamonkeys.com/blog/2007/04/26/estimation-considered-harmful.html