Tech talent hiring knowledge & best practices straight to your inbox!

Estimating Programming Tasks


Sleeping under the chair, working long hours are almost common traits of a programmer – it has become so common that you wouldn’t be accepted into the geek community if you haven’t done the above. But I asked the geek I am close to, on whether it’s actually essential and found an interesting answer/method that I have begun to follow. The credit to the following points goes to him who is lazy to write a blog post.
So, how do you estimate programming tasks at work ? A simple answer – DON’T ESTIMATE :-).
Lets say you have a task at hand – Build a codechecker which would evaluate a code snippet against a test case and return the result.


Phase 1: Study

  • Break down the task into atomic sub-tasks. There is absolutely no coding involved here. It’s simply breaking down tasks, viz. designing table structure for code submissions, desired prototypes of the function, communication should be done over XML/SOAP/JSON,etc.
  • Get down to the research mode to identify which protocol/database-type (couch/mongo/MySQL) would be ideal for your component
  • Just as a website/page can’t be designed without a wire-frame, similarly the structure or a pseudo-code would go a long way in clearing out the blockers you might face later. Get the structure and pseudo-code ready.

You still can’t tell your manager how long it would take for you to complete the task, you just completed your research :-).


Phase 2: Code
Now that your pseudo-code is ready and you have done enough research, get down to programming 1 sub-task in the list. Lets say it takes x days. As said, the best way to estimate the task is by doing it!
By definition of our sub-task, each one is atomic and is indivisible. Hence the total time that would be required to complete the task = n * x where n is the number of sub-tasks present.
That’s just the 70% of the total time required ,T days (i.e) 0.7 * T = n * x. The remaining 30% goes for bug-fixing, “unexpected errors”, etc. And hence, you arrive at the total time required to complete the task.
In workplaces you would be required to take ownership of an entire component and this helps a lot in arriving at a good estimate of the time required. Whatever role I play, I think programming would definitely be a part of me and happy to have learnt a way to estimate them. Let me know your thoughts/feedback and how it worked for you.
Image src: http://farm3.static.flickr.com/2416/2522802875_f095c0a40d_m.jpg
(This post originally appeared at http://rvivek.com/archives/1085)

Would you like to receive similar articles straight to your inbox?