One of the most debated, often confound and misconceived issues of web development is estimates. Nevertheless, this aspect is required, and we have previously written about how our team estimates our Drupal projects. However, lots of people, especially laymen, don’t realize that asking a development team to estimate a project and answer the questions ‘How long will it take?’ and ‘How much will it cost?’ equals asking them to foresee the future. We can only give a definite answer after it has happened. With small or big divergence, estimates are always wrong. When they are right, it is purely accidental. Today we are going to name challenges programmers are facing when they have to make an estimate, to clarify what makes this stage of project developing so ambiguous and hard.
Too much optimism
Most programmers tend to make overly optimistic estimates. They either overrate their productivity or underrate the complexity of the task. This is especially true for new developers who are too confident in their abilities. Making estimates as precise as possible requires much experience, practice, and knowledge of the existing system and task. Also, some companies prioritize timeliness over robustness. This strategy may not always produce satisfactory results, because as people say, haste makes waste. It’s better to under-promise and over-deliver.
Updates
When some estimates for a part of the project are not reached, other estimates should be corrected accordingly. However, programmers are usually optimistic and believe that they can do the rest of the tasks more quickly and compensate for lost time. However, the opposite is usually true.
Also, in most projects some alterations occur in the requirements, either from the customers or rational suggestions from the developers. During the time of working on web project, new ideas appear. It’s obvious, though, that any added feature influences the estimate for the whole project, which should then be re-estimated accordingly.
Membership of the team
Programmers differ in productivity a lot. The situation is better when programmers estimate their own work than when someone else does the estimation for them.
Don’t forget also that the members of the development team, like people of any other occupation or craft, may get sick or go on vacation due to unexpected personal issues in the middle of a project’s developing process. Changes in the team’s membership have an impact on the overall picture.
There is a term ‘man-month’ — one person's working time per month. It’s used to measure how much work is needed to accomplish a concrete task. It is considered that a unit of work is proportional to the number of people working multiplied by the time they work. Frederick Brook in his book ‘The Mythical Man-Month’ disproved this correlation, relying on his experience and observations about what causes most projects’ delay. Brook affirms that adding manpower to a late web project which is running behind the schedule makes it even later. This is because the time required for the new programmers to grasp the main idea and go deeply into the project increases time for communication inside the team.
Accidental complexity
In the web development process, either an essential or accidental (non-essential) complexity may occur, or both. Frederick Brook, in his other book ‘No Silver Bullet,’ distinguished between those two types and described them.
The first one is directly connected with the task itself and with customer’s desire and requirements. It’s a core of the problem that must be solved anyway, that’s why essential complexity is inherent and unavoidable. It cannot be simplified without losing value.
The second type of complexity is coincidental and unpredicted. It concerns the problems created by developers, which can be fixed. Accidental complexity relates, for example, to nuances of writing assembly code or delays caused by batch processing. This complexity can be caused by the approach chosen for problem-solving, by disorganized planning, or low priority put on a project, but there is also an accidental complexity that always arise as the side effect of solving any problem. And, of course, it requires some extra time and efforts.
Bugs and blocks
Even the best and most experienced developers can’t foresee all the obstacles and bugs that will occur. Therefore, a proper estimation should take into consideration the high probability of them happening and have some reserve for these things. Our team includes QA engineers, responsible for testing the process to make sure that all quality requirements are fulfilled.
Mechanical vs creative tasks
Mechanical and routine tasks can often be automated to some extent. They are more predictable. If programmers already had some practice with the previous similar tasks, it’s not as hard to estimate them.
Creative tasks need much thinking and inspiration. The more of them there are, the more time each one requires. It’s almost impossible to estimate these creative tasks with adequate accuracy.
Why is estimation needed, anyway?
It’s important to assess the value of every feature, no matter how small-scale it is. If all features are equally effort-consuming, you can simply create a list with no sequence and start doing them. However, features vary depending on the different amounts of efforts and the time they require. So, estimating the approximate cost of features allows you to do cost-benefit analysis and prioritize features.
As a large estimation of the entire project is more likely to be wrong and have bigger errors, it’s a good idea to break it into several smaller estimations. This also helps to structure work and to single out milestones.
Conclusion
As long as programmers are not fortune-tellers, their estimates are still only guesses and suppositions. So, it’s wise to accept that estimates are always wrong, don’t rely on them totally, and don’t panic if they are not reached. Meeting estimates isn’t a criterion for developers’ competent judgment. Moreover, following the initial plan may improve estimates, but also may lead to mediocre results, because it kills creativity and striving for perfection. Re-working should be encouraged to improve things, but it’s quite hard to find a balance between re-working in the context of the current project and the creation of a new one that will be implemented later. This is a chance to discover new dimensions and perspectives.
Every project is unique. No two are the same. It’s obviously impossible to estimate the unknown with 100% accuracy until it is discovered. Plus, life is always unpredictable. So, let us pleasantly surprise you with the estimation and end result of your website development process.