Sticky Notes of Thoughts

…because some thoughts are worth remembering

On Interpreting Programmers’ Estimates


“But it’s a quick hack,” I’d hear my programmers say. “We can do it. It’s a five minute job.”

How many times was I tricked into including an extra feature at the urging of the programmers, and regretted it because it took significantly longer than they estimated?

It’s important to get an accurate estimate because we use these estimates to weigh the pros and cons of including an additional feature. It’s important because a delay in the coding job can cause delay in the actual roll out of a new service, triggering a chain of issues from internal strife to customer grief.

Then someone told me a good rule of thumb to translate the programmer speak for managers’ project planning purposes:

  1. Where x is the number of specific time unit programmers estimate, double the number.
  2. Increase the time unit being used to the next unit above.

Using the above heuristic, “a five minute job” estimate made by a programmer becomes:

2 x five = 10; minute upgraded to the next step up = hour; therefore, a five minute job should be considered as 10 hours, for project management purposes.

I’ve used it consistently since then, and it works like a charm.

Photo: Atlanta, Georgia

It isn’t so much that the programmer usually lack the ability to judge time or think they have more coding mojo than they actually do (though both may be true). It’s easy to come up with an estimate for just the initial coding process: not the debugging, the placing of comments, the testing at the end to make sure the rest of the program weren’t negatively affected, etc. Further, programmers do not usually take into account tasks others take on after the coding is complete: updating the documentation for client manuals, training of staff of the new feature, etc.

The work around is this estimate-translator formula. But if you are interested in addressing the root issue, that the estimates you receive from your staff should be more accurate, I thought about training at two different levels:

  1. At the programming level, there is a whole discipline within software engineering called Personal Software Process
  2. Cross-training programmers to shadow system/network administrators, tech support, sales and marketing staff expose them to tasks their code will affect outside of their domain.

I am picking on programmers here, but I’ve experienced similar situations with green project managers and middle managers. When in doubt, I use the conversion formula for less headaches at the end.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s


This entry was posted on June 19, 2015 by in Management and tagged , , , , .
Follow Sticky Notes of Thoughts on
%d bloggers like this: