A Difficult Software Developer who consistently massively underestimates the amount of time needed to complete a task.
- Can mutate into: “The Extreme Overestimator” Developer
- Dangerous when coupled with: “The Optimist” Project Manager
- Likelihood of fixing: High
- Danger to project: Medium
Underestimation is such a pervasive symptom in the software industry that people do not even think to call it out as a problem. Everyone, everywhere underestimates tasks, and in many cases, it is accepted as part of doing business. However, The Extreme Underestimator developer takes this to an entirely new level, as they can always be counted on to miss their deadlines by large margins.
The Extreme Underestimator’s impact to the project is simply one of predictability: Without good estimates, it is impossible to plan for the future. Software release deliverables are sometimes tied to contractual obligations with customers and/or partners, thus making predictability a business necessity. A little unpredictability is to be expected, as the reality is that the entire software industry is built around the fact that one cannot accurately predict how long writing software will take. The Extreme Underestimator abuses this tolerance for being late by delivering their tasks weeks late, when their original commitment is that of a couple of days; or worse, months late when they committed to a couple of weeks.
The Extreme Underestimator fundamentally does not grasp the negative impact these kinds of schedule delays have on the overall success of the project. They may also consider estimation itself to be a useless practice, as it is their belief that nothing can ever be accurately estimated. In this way, they may come across as blasé when asked for estimates, or arbitrarily throw out a number when asked for how long it will take without any form of analysis.
Thankfully, The Extreme Underestimator can be fixed, but it does require several guidelines to be followed:
- They must only be asked to estimate in codebases in which they are intimately familiar.
- They must only be asked to estimate when using technologies they are intimately familiar.
- Never ask them to estimate on new features, only enhancements to existing features.
- Care must be taken to ensure that they fully understand all of the requirements – they cannot be given the liberty to make requirement interpretations on the fly.
- Require The Extreme Underestimator to add “TODO” comments in the areas where they will have to make changes. This will reinforce the dependent relationship between software complexity and estimates.
- Make them accountable by presenting their estimates to a group qualified to challenge their timelines.
After The Extreme Underestimator has gone through this process a few times, and delivered on their commitments, you can begin to trust them in estimating new features in codebases and technologies they are less familiar with.
During this rehabilitation process, pay close attention to the way in which they are meeting their deadlines:
- Has their quality suffered from them taking shortcuts to make their dates (see “The Bull in the China Shop” Developer). If so, encourage them to add the requisite time for testing.
- Are they working overtime to make their dates (see “The Soldier” developer)? If so, encourage them to add the time necessary to ensure work is completed during business hours, and that overtime is for contingency and should remain as such.
Provided The Extreme Underestimator takes their rehabilitation seriously, they have the opportunity to grow into a highly trusted member of the development team, as trust is given to developers who deliver the correct requirements, with sufficient quality, at the date committed to. Once prove they can do this consistently, it can be justification for promotion or a raise, which itself can be offered as an incentive to commit to their rehabilitation.