Determining time estimates for development projects: A non-dev´s perspective

April 8th, 2010

1

As an engineer specialized in industrial processes, the subject of determining time estimates for  software development projects has been something that I’ve always found very interesting.  

Non-developers usually have no understanding at all about programming. They do not understand the considerable intellectual challenges that come with it. Every new design is a totally new problem. Coding one day can be like building a water dam, the next day a skyscraper and the following one a cargo port. In the end, they are all three examples of building efforts; however, the implications, required abilities and intrinsic challenges vary completely. The question is then, why are software projects always so different from what has been done before? The answer is: no matter if you reuse code from other projects, every new software project has new endeavors that actually push the limits of what is possible. There is no precedent, or reference on how to approach them. 

In school they teach you that there are several methodologies specifically for calculating how long a dev team is going to take to finish a program. However, based on my experience of working with developers, I have concluded that such methods just don´t work as they are supposed to. As a matter of fact they are rarely used. According to what I’ve experienced, these are the reasons why they don´t work:

• The main reason is probably that an endless amount of, not only unforeseeable, but also never-seen-before complex problems arise during the development process. Getting time estimates for them is considerably subjective.

• Every language has its particularities, and hence using a calculation method that was based on other generally older languages, completely changes the conditions. When people say “hey lets use COCOMO on our Ruby project” they don’t understand the underlying contradiction.

• Every developer is good for different coding aspects and there is no way to standardize their abilities, period.

• As the programmers start to code, new software updates come out in the market, old versions sometimes become outdated, hardware requirements change and a bunch of other unforeseen tech variations always take place.

• New developers join the team and occasionally some of the original members leave too. The effects caused by these changes are sometimes considerable. It takes a long time to understand new code bases, period. 

• Programmers will hate me for this one but: edge cases. Trying to solve edge cases can consume huge amounts of time and resources. “What if the user enters a thousand-character-long username? Ahh? We have to be prepared!” I would say "Whatever!!! “Focus on the most relevant stuff, leave the minor hipster tweaks for the end!”

After long conversations with experts in the matter and doing some research, I’ve concluded that the most successful way to estimate software development times is by:

1. Dividing the project in several parts, then get a group of developers with experience IN THAT TYPE OF WORK to determine rough estimates.
2. Coming up with roadmaps, iteration plans and budgets.
3. Loosening the constraints between the components as much as possible. You might not be able to determine estimates for 2 parts out of a 10 component software, but if you can get the estimates for the other 8, then you have something to work with. 
4. Always adding more time for unexpected events that ironically will most likely take place 

Once a developer told me his “dev time estimation rule”, it went like this:

Ask a developer how long is he going to take to develop the system. If you feel the estimate is doable, then multiply that number times two. If you still think it’s something you can live with, then multiply it times three. If you then are all pissed off and you look like Jack Nicholson in The Shining, but you still think there’s a good chance that even then the program would be useful, then, and only then, you’ve found a realistic estimate. 

(image source)

Tagged with:

Related Posts

Author