Members Only Logo  

or Subscribe by Email by entering your address below:

Powered by FeedBlitz
Learn about Subscriptions Follow me on Twitter!

The topics discussed here grow out of the bread-and-butter issues that confront my consulting and software clients on a daily basis. We'll talk about prosaic stuff like Membership Management, Meetings and Events Management and Fundraising, broader ideas like security and software project management, and the social, cultural, and organizational issues that impact IT decision-making.

Monday, June 11, 2007

Estimating Programmer Time

I've had a few questions in my mailbox recently about this subject -- and as leader of a company that provides software development services, it's one that is dear to my heart. Our usual way of working with our clients is to estimate the time required for any requested programming task, and to guarantee we will come in within 20% of that estimate. So arriving at an inaccurate projection can really hurt.

The good news is we've gotten better at it over time; the bad news is that it is not easy, and there will inevitably be occasions when a task takes much longer than expected to complete. Here's what we've learned over the years.

1. The starting point - look at how often you underestimate and compare it to how often you overestimate. You aren't really surprised, are you? All developers have a tendency to underestimate how long a task will take. Programming provides one of the most clear-cut examples of that oft-stated law: "Everything takes longer than you think it will, even when you take this law into account." Understanding the factors that lead to this is the heart of becoming a better estimator.

2. The most important tool you can have handy when trying to estimate is a database of how long things have actually taken you in the past. If you do not track your time - your entire group's time - against specific development tasks, you should start doing that now.

3. Estimate in pairs. Your accuracy will go way up.

4. Here's the key: remember that the bulk of a programmer's time is not spent actually writing the new code, but in (1) figuring out how the existing program works, (2) determining where to make the change, (3) verifying that the change actually works, and (4) debugging any problems found. These are the times that are hardest to control, and are the most often overlooked: novice programmers habitually underestimate the likelihood that problems will emerge in testing.

5. To manage this, include estimates of "design and analysis" time, and "testing" time, and assume some time will be needed for debugging -- even in what seem to be the simplest modifications or enhancements. Remember to include time for defects found not just by the programming team, but by customers and end users after the item goes into production.

6. Be willing to revise the estimate after the initial few hours of the work. Perhaps the estimate was based on the idea that some new components could be dropped quickly onto a form. But it turns out the form is so crowded with widgets and gizmos that it needs to be completely re-structured. If good estimates are needed to track costs or delivery dates, programmers need to become alert to the fact that discoveries which will affect development timelines need to be reported immediately so other stakeholders can revise their expectations.
image originally uploaded as

Labels: ,

Comments on "Estimating Programmer Time"


Anonymous David Zeidman said ... (June 13, 2007 at 9:11 AM) : 

As a fundraising consultant specialising in software development, I found this post interesting. There are a couple of questions about it though. Who is it aimed at? Is it the organisation that needs to work out if an estimate is reasonable or work out whether they think they have the budget for some development? Is it the project manager running such a development project and needs to estimate times, or is it for the individual programmer who needs to give an estimate of their work? I assume if it is from your own perspective then it will tend towards the project manager role.

Each of these groups will make use of your posting but they will arise at different answers.

It is unlikely that an organisation are going to have so many development projects under their belt that they are able to estimate how long a project is going to take from previous experience. All they can hope for is the experience of their own employees who may have worked on projects previously. Even the more high-tech organisations may be unfamiliar with the technologies required to solve solutions, let alone work out how long it ought to take a programmer to develop. The most likely solution for them is to work out what their budget allows them and then explore the viable alternatives with a third party that is able to make a better stab at what is possible.

The project manager may have the historical experience of previous projects to look back on but they may not have the current technological knowledge required for the project. Even the most routine mundane projects can have pitfalls. It is only through the careful analysis of the project that any accurate estimate will come to light. This means working carefully with the client and with the programmers.

The programmers may be best placed to make an estimate but this will depend on how well specified the project is. They can only give an estimate based on the client’s specification. It may be the responsibility of the project manager (or equivalent role) to investigate and get clarification from the client. The programmer can all too easily sit in their own world and not be aware of the implications of time estimations based on technology that will have to change once the full picture of the project emerges.

In short the best estimates arise where all three groups are speaking to each other. This seems obvious but many projects are started where this is not the case and the results can lead to the developers having to cover the cost of an overrun or the organisation having to pay over the odds for a project that could have been brought significantly under budget.

David Zeidman


Blogger Michael Stein said ... (June 13, 2007 at 9:35 AM) : 

David - thanks for these insightful comments. You are right that I was not clear who my intended audience for this post was - the actual question that prompted the post was from another development group, and without articulating it clearly, that's who I was aiming my comments at.

I do find that very often the programmer, even if he is very familiar with all the technologies involved, is a poor estimator. Indeed, it has taken us here at my little company a long time to learn not to habitually underestimate.

Indeed, it is our careful time logging that has helped us understand just how badly we tend to underestimate, and just what types of eventualities we fail to plan for.


Blogger Eduardo Ibarra said ... (July 15, 2007 at 6:10 PM) : 

Totally agree with the quote "Everything takes longer than you think it will, even when you take this law into account." As a Software Project manager I started using a Balance Factor (1.2) to brich the gap between Project estimation and real time. I have better results


post a comment