As software engineers, we will be asked more and more to provide estimates for bug fixes, small updates, and new features. I understand the immense value of having estimates. It allows project managers and tech leads to plan tasks, plan a larger project, and provide timelines to clients and users. Estimates are valuable generally in day to day life. Just to name a few examples, we receive variations in the form of weather forecasts, stock market analyses and predictions, and seeds assigned to NCAA teams. However, estimates for software pose their own stakes and challenges.
Why? What’s at stake?
The value of our estimates may build up to predicting profitability of projects and business in the future. They will assist in any decision making and planning. And, they will help to set expectations and avoid surprises.
Great, what’s hard about estimates?
Given what’s at stake, it’s easy to see why there is a connotation of commitment and why engineers are wary to commit. However, I will try to rattle off a few quick ones:
- sometimes, a task just has to be done, and it takes as long as it has to to avoid harm
- we are being asked to estimate work we may not even carry out or in other words, estimate for someone else to do the work
- we are being asked to place estimates situations with uncertainties
- we may perceive it as a detriment to crucial work being done correctly
How can it become easier?
The answer to some of the concerns stated earlier is perhaps trivial. Provide us the bigger picture! The bigger picture might be answers to these questions:
- Why do you need an estimate?
- Who will carry out the work?
- What if we are wrong?
- What happens if we find that we cannot meet the initial estimate?
- What other work depends on us meeting this estimate?