Misusing Software Estimates
Estimates are a useful tool, but meeting them shouldn't be the end goal.
I like software estimates. I really do. They're an essential part of prioritizing work. Creating a fun little feature could be worth it if it took a day, but completely absurd if it took a year. Every software project is concerned with getting a good return on investment. Even open source projects want to make sure their time is utilized well and spent on meaningful things.
The problem with software estimates is the compulsion many people have with getting exact numbers (wouldn't that be an exactimate?). To understand why this is a terrible idea, I'm going to go into a small tangent about utility.
The concept of utility is incredibly useful. Someone seeing a salary increase from $50k to $100k is going to have a big change in their life. That's the difference between falling behind on bills/rent and being able to save money. That's the difference between worrying about putting food on the table versus worrying about what to fill your belly with. That's the difference between worrying about tomorrow versus planning for years in advance.
That difference is $50k in absolute numbers and 100% in percentages. Take those same numbers and apply that to a person making a $200k salary. Going from $200k to $250k is a fairly minor difference. The person will likely just see their bank account increase faster, but won't see a huge lifestyle difference. Even a salary increase from $200k to $400k isn't as impactful as going from $50k to $100k. What would someone do with that increase? Get a slightly bigger house? Fly first class? Gain weight by going out to eat every day? None of those things are as life changing as going from worrying about being hungry to not worrying about being hungry.
Please don't ask me how I came up with that last example.
Utility is the actual value a person gets from something. If that something is quantifiable such as money, utility does not necessarily correlate with an increase/decrease in money. The more money you have, the less impactful incremental increases will have on your life and therefore the less utility it provides.
The concept allows us to make better decisions with our life. If our salary is low enough that we worry about survival, our logical concern is to focus on making more money. If our salary is high enough that we don't worry about survival, then leaving a job for a higher salary may not make sense depending on a host of other factors.
That doesn't necessarily mean no amount of money past $200k can provide the same utility as going from $50k to $100k. I'm guessing that going from earning $200k to earning $1 billion is likely more impactful. The question is, how do we calculate utility? Where are the thresholds?
Some economists concern themselves with trying to put hard numbers on utility. For the rest of us, does it matter at all? The concept is useful because we can account for big differences in our decision making. Small differences are largely irrelevant. I'd struggle to understand if someone leaving a job making $200k for a job making $205k did it for the money.
Software estimates have the same characteristic. It matters if a task takes minutes versus days versus months versus years. It's largely irrelevant if a task takes 5 days instead of 3. If you feel that is wrong, consider this. We want what we build to have an impact right? The software should provide our customers with some utility right? If we look at a simple calculation for prioritizing work it would be:
Value of work / Time to implement = Return on investment or Priority
We just went over how it can be difficult to calculate utility and how exact numbers are usually irrelevant. So that leaves us with a fuzzy number as a numerator. If the numerator is fuzzy, does having an exact number for the denominator do anything? Is it useful in any possible way?
"Well, it let's us plan so we know exactly what goes into every release." is what your boss is likely going to say. I ask again though, does knowing what goes into each release ahead of time matter much? Are your customers going to care? They're going to want value from your releases, but they're almost certainly not going to calculate the exact utility of those releases. They're likely to not care that you didn't have time to implement that last widget. The only question that's worth answering is if the release was impactful for them.
Calculating "accurate" software estimates does not come free either. How much time do you spend in planning meetings trying to come up with estimates? How much time is spent on discussing the estimate for 5 minute tasks? How many hours or days do you spend trying to estimate big features?
Most experienced software engineers can give you general estimates for small to medium sized tasks instantly. Our intuition is usually good enough to know right away if something is going to take minutes, hours, or days. Big features may take slightly longer to create a rough estimate, but probably doable in a single 30-60 minute meeting. The time saved in accepting that general estimates are good enough is immense. A lot of software can be built and a lot more utility can be provided to customers if less time was spent estimating and more time was spent building. In the end, that's what your customers care about. It would make sense if that was what we cared about too.