As programmers or developers something we get ask by others a lot is “How long will it take”? To the person who is asking the question it may seem like something simple to answer, but the reality is it is not. In fact, it is a very loaded and open-ended question.
When I faced this question for the first time, I was uncertain on how to answer it. I just threw out a number in months and fortunately, for me it did not put me in a hole. However, that experience made me realize I need to give better estimates.
Overtime, I have been getting more experience with giving an estimation and what I learned is it is nearly impossible for me to give a slightly close to accurate estimation. I am going to share with you some of the obstacles that I had faced, which made estimation so difficult.
Project is poorly specified
The tasks are too ambiguous, which leads to a lot thrashing on how to implement them. In some projects, you may even get a request or feature as “flexibility”. What the client wants is a system that handles anything they want in the future, although they have no idea what those features might be.
Task creates new tasks
In order to do one thing, it may require many other hidden prerequisites. At the time of giving the estimation, you are not even aware of the prerequisites. This requires you to go do research, learn, and implement a solution for the prerequisites.
Research tasks with non-tangible outcomes
You might spend weeks to research and prototype some solution. This goes back to how one task may lead to several research tasks. It gets worst when you are working towards larger ambiguous tasks. Without constrains, you do not know when to really stop and might waste time by researching too far.
Estimates made for unfamiliar technologies
Sometimes, we might not even know what technologies to use for the project. Estimating for all the potential roadblocks and time to learn is impossible. This is a case I would like to call “unknowns nested within unknowns.”
Task with dependencies
Unless are you working by yourself, chances are each person or team is in charge of a task. Developers can become immediately blocked if prior tasks are not finished. This becomes problematic if several people or teams need the dependencies.
Working on unrelated tasks
Developers tend to focus only on one project at a time because usually a project requires their full attention. When they are given another task in-between that is not related to the project, it forces them to make a context switch. Even if the new task is a minor and short one, it will hurt the developers’ progress for the project. Once a context switch occurs, it takes some time (days) for the developers to re-focus on the project again.
The project scope changes
This is one of the most irritating problems I encounter as a developer. A feature requirement is changed or added midway during the project. The reason usually is that someone higher up thinks it is a cool idea or changes his or her mind.
Usually, when this happens, you lose a portion of the work you have done for that feature. In the worst case, a feature is completely different from before and you lose all your progress for that feature. Sometimes, a feature can revert to the original feature because someone changed his or her mind again. Whenever this happens, you lose a lot of time with no progress towards the end of the project.
Testing time is forgotten
It is nearly impossible for me to test my own code adequately at times. I test my code in different ways and I cannot find anything wrong. The problem seems to stem from the fact that I know exactly how it should work. So I consciously or sub-consciously test in specific ways.
To get around this, I often ask a team member to test my code. Sometimes by just observing how they interact with my code, I can think of new ways to test my code. In general, you can expect to spend another 50% of the development time for testing and debugging.
Whether or not you have experienced any of the issues with software estimation I have mentioned, I believe we can agree on a few ideas:
- Software estimation is difficult
- Many developers or teams fail to accurately make estimates
- There are too many unknowns to account for to give an accurate estimate
Are there any other reasons that can throw software estimation off that you have encountered? If so, feel free to leave a comment. To get in touch, you can follow me on twitter.