The fine art of estimating how long it takes to create software

How to estimate programming time

Flavio Copes
estimating programming time
© Shutterstock / Artur Szczybylo  

One of the biggest challenges for developers is to estimate the programming time of an application. If you are looking for solid advice on the matter, Flavio Copes got you covered.

I really want to tell everyone how I estimate the time needed to build software projects.

In the past 10 years, I’ve been asked these question hundreds of times:

  • “We need to implement this feature. How long is it going to take you?”
  • “Give me a detailed overview of how much time this project is going to take in terms of time. 1 month? 2 months?”
  • “I want you to ship this. 50 hours of billable time are enough?”

The answer to those questions has either been a bet, in the most optimistic case or a leap of faith, knowing that if I promised a number, that would probably have been my paycheck regardless of the actual time it took.

Sometimes with long term clients, I was able to amortize the projects that exceeded my estimations with projects where I completed the work earlier than I expected, letting the client know.

Ultimately I ended up saying “I can’t estimate”.

So, the answer to “I really want to tell everyone how I estimate the time needed to build software projects” is: I don’t. But I can estimate that no one is really able to estimate when it comes to building software, because of the inner complexities that this field can put against you.

SEE ALSO: How to become a full-stack web developer

“Real engineers” are going to find this hard to admit, but I’ve never been your typical real engineer type. Estimating is probably the hardest thing when working as a developer.

Here’s a cool reference table you can use when you need to estimate a task:

This might be a good estimation of our lack of estimation, but of course, things can also work in the reverse: a thing you estimate might take 5 days might only take 1 day because you find everything is already in place to add it, and it takes much less than anticipated. Some might overestimate, projecting they might have difficulties, adding a 30% more of what they think. Team projects estimation is even harder, I won’t even try.

What to do then?

Instead of detailed estimating, I propose continuous communication with the client or boss or whoever commissioned your work and do weekly checkups on the project progress. Without pre-defining when the process will end.

Because after all the process will never end.

This article was originally published on Flavio Copes’ blog.


Flavio Copes

Flavio is an Indie Hacker and Computer Engineer. He writes tutorials for devs on Tutorials for Coders The Vue Handbook, and Vue.js Essentials. Follow him on Twitter @flaviocopes.

Inline Feedbacks
View all comments