I’ve looked at two problems that are caused when you don’t refactor, code duplication and test duplication. Both of these are mainly technical problems that affect developers. Today I want to look at a problem that affects project managers and everyone else on a team, wild estimates
Wild Estimates
When an application is well refactored, with short and clear methods, it’s easy to estimate how long a change will take. This is because there will be only a few places in the code that would need to be changed and there would be less unintentional changes (bugs).
But, if an application hasn’t been refactored it becomes harder to accurately estimate the impact of a change. What might look like a small change to one method, ends up requiring you to duplicate that change to six other methods (from code duplication). Or a simple code change suddenly breaks half of your tests and you spend half a day fixing them (brittle tests and test duplication).
This leads to wildly inaccurate estimates (more like guesses). What might only have taken an hour to do last month, might take three hours this month. So your original estimate of “maybe an hour” is now “maybe an hour, but it could take three or four after I rewrite then entire class”. This uncertainly makes it extremely difficult for the team to plan.
The one way I was taught to counter these wild estimates is to always estimate the “worst case” and pad it. So a task that I think would take one hour would be estimated as 2-4 hours. I found some big problems with this, so I stopped using it:
- it’s dishonest
- when you are outside of the range, your estimating skills are questioned
- managers have learned about this “technique” and will reverse pad it
Dishonest estimates
Every developer who is paid for their work needs to be honest. If you are a professional, then you need to act like one. Giving yourself a padding is fine for planning as long as you communicate this padding to who ever is going to use it.
This means I’d tell my client “I think if everything goes as planned, I can complete this task in one hour. But in something goes wrong, we should budget 2-4 hours for this just in case”. This way, my client can make the decision if they want to base their schedule on my optimistic or pessimistic estimate. This requires a lot of trust on both sides of the conversation, trust that can be eroded very quickly when things go wrong.
Questioning your estimating skills
If I give an estimate of 2-4 hours several times and every time I finish them in an hour; my project manager is going to question my estimating skills. Do this enough and their trust in your skills will vanish.
Once the trust is gone, when you say “2-4 hours” they will hear “1 hour”. This is very dangerous to the project because when a task really does take 4 hours, their expectations will be shattered and along with any remaining trust in you. I’ve seen several project managers formalize this practice into a something called reverse padding.
Reverse padding
Project managers aren’t stupid, not matter how often Dilbert says so. When they start noticing that you are padding your estimates by doubling them, they will thank you for the estimate and reverse pad it by dividing it by two. In the most extreme cases I’ve seen, inexperienced project managers might latch onto the lowest estimate said:
What a developer hears:
Project Manager: How long will it take you to streamline the dot-com platforms?
Developer: Well, it took us two days last time to do this on the Blue Platform but the dot-com platform is more complex so it will take about three to five weeks.
So what’s the estimate here? Three to five weeks. But what does the project manager hear?
Project Manager: How long will it take you to streamline the dot-com platforms?
Developer: Well, it took us two days last time but blah blah blah three to blah weeks.
Project Manager (thinking): So the estimate is two days to three weeks and since they are probably padding the three weeks number, lets just use two days.
Good thing both the developer and project manager are close huh. Three to five weeks versus two days…. that’s going to cause a conflict later.
Solving the wild estimates
To get back to the root of the problem, there are a few things developers can do to prevent wild estimates or diffuse the problem early on. The ones I’ve used are:
- spend extra time communicating what an estimate actually includes
- talk honestly about the quality of the code and any existing risks that might come from changing that code
- don’t estimate in time and use story points or tomatoes (this is an extremely hard thing to do in a client/consultant relationship)
- spend the extra time to refactor code as you go
Of all of these, the last is the easiest for a developer to do over time. Refactoring only takes a few extra minutes and you’ll earn back that time the next time you’re asked to estimate a feature. The hardest thing is being able to recognize potential refactorings and know the difference between a 5 minute refactoring and a 5 hours refactoring.