Software engineers are notoriously bad at time estimation. When they receive a new bug report or product feature to work on, engineers are often asked by their project manager to guess how long it will take. It’s a very reasonable request. For example, if your website goes down, public relations needs to know how long it will take to put together a response. If you’re working on the next version of your app, product management needs to know what features are possible before the ship date.
Unfortunately, engineers are bad at time estimation. A “one line fix” can become a rabbit hole when that one little change has massive implications across the rest of the code. A big project might be very simple to complete if a lot of the pieces were already lying around. This mismatch between apparent and actual complexity makes estimation. However, engineers often don’t even know what they will find until they are deep in the code. And by then, they will have already committed to a bad estimate.
Engineers have plenty of tricks to avoid blame. They make a real estimate then immediately double it, just in case. “Under-promise, over-deliver” is a popular strategy. However, both of those hide the original problem of making a good estimate. These tweaks only work if you’re original estimate within an order of magnitude. If your estimate is wildly off, then your fluffed estimate will still be wildly off.
If you’re looking for a solution, I don’t have it. However, I realize that there’s tension in how have been explaining and using time estimation on my team. That tension is rooted in the difference between Daniel Kahneman’s “System 1” and “System 2” in how humans think. Continue reading Is Time Estimation in Software Engineering a System 1 or 2 Task?