How long would this project take?

This is one of the questions I get most often and one of the hardest to answer.  The best way to answer this question is to answer in FTEs (Full-time Employees).  It is fairly easy to do because you just find some features that don’t have a lot of overlap and you assign them to different people.  Once the features have been divided to the smallest groups possible, you could the number of people and that is your answer.  You cannot develop this project any faster than this.

“It takes 9 months to make a baby no matter how many women you assign to the task”

“Men and months are only inter -changeable when a task can be partitioned among workers with no communication between them”

“Adding more engineers to a project makes a late project later” (because people who should be working are now training new people on the project)

– The Mythical Man Month

Unfortunately for me, most people also want to know how many calendar months a project will take as well.  This is tricky because up to 90% of software costs happen after release.  This comes from bug fixes, absent features, performance improvements, supporting new platforms (android can be a big culprit here), or just re-writing some poorly written code to reduce technical debt.  Even before the project is released, defining how to handle every error case gracefully can’t be known upfront.  To a certain extent you will always be asking, “I have a problem I want you to solve but I can’t tell you what the problem is.  How long will it take to solve it?”

Even though providing estimates is hard, developers ultimately need to figure out a way to come up with one.  While there is no exact answer, I have found 3 ways of approximating how long projects will take:

1. The best way to figure out how long something would take is by using a comparable project that the coder has already done.  This is pretty possible for simple web pages or apps.  Or anything that requires standard CRUD (future post to explain that).  Note that this is much more possible when the project is small and simple.  It is also common to be able to use this method on version 1.0 but not on future versions because you are distinguishing yourselves from competitors and therefore writing code that has never before been written.
2. My good friend and past co-worker John Walker (not this John Walker) likes to use this method.  Divide the project up into the smallest tasks possible.  Write down how many hours, days, weeks, or months you think each task will take.  Apply the following conversion: If it takes hours, say it takes a day. If it takes days -> a week.  Weeks -> month.  If it takes a month or more, you have no idea how long it will take or what you need to do.
3. I came up with my own way of doing estimates which ends up being pretty similar to John’s.  Divide each task into the smallest sub-task possible.  Estimate the worst case for how long it will take  each piece to complete.  Add up all of the estimates and multiply it by 4.  Round up to the nearest prime as a sarcastic way of protesting the futility of this exercise.

For large unique projects developers can rarely know how long it will take.  It’s like asking “how long will it take you to find a cure for cancer?”  However, most management teams refuse to accept that answer and so developers do a little dance where they figure out what you want them to say and then try to add a little padding.  What else can they do?   It is common for corners to get cut because people are trying to meet a deadline that should have never been created.  You need to understand that sometimes estimating is hard and allow for changes to the schedule to happen.  Until your coders can break their tasks into pieces smaller than 1 month, do not plan on any marketing events surrounding your release.

The last thing to consider is that when you are creating new features on top of an existing project (ie. version 2.0, 3.0, 4.0…) you should add an additional 20% for rework (coders call it refactoring) of the existing codebase.  This is to pay off technical debt (read the article in the link) or invest in code that will pay off in spades down the road.  People view Google’s 20% time as a way to create new innovation, but I’ll bet most of it is really just paying down technical debt.

Estimating how long something will take is hard and frequently impossible.  Even if you have been able to do it successfully in the past with small projects, it will get more difficult over time.  It is a good idea to make sure your developer is applying some kind of padding to his numbers.  Many younger coders haven’t always figured this out so you may have to just multiply their estimates by 4.