It is common for legacy products to have a lot of technical debt. How to manage estimating bug fixes or new features?
Here’s an example, the team decides to jump 2 versions ahead with their Java installer software. The new version installs Java 1.8 as the default JVM. The product needs 1.7,which of course is determined during testing.
While product A was able to get receive the installer update without a hitch, product B had this and other customized (and un-documented) build/configuration steps. Product A was recently updated to Java 1.8.
So if one offers an estimate on updating the projects, even with A’s experience, the estimate is likely to be off by 100% or more. When dev’s provide estimates, there is a natural inclination to meet that estimate (in terms of calendar days, not hours), as a matter of professional pride.
Stepping back, it’s clear estimating has many problems, especially as it destroy’s the business’s ability perform any planning. The status quo has the developer asked to perform it again & again. If however, the business set a budget for the change, then a great learning opportunity smacks everyone in the face. It’s far better for development to ask the business for a budget. If business doesn’t like the outcome, then the assignment should be transferred to another team to validate or explore other options. This in and of itself is a great learning opportunity for that team as well, as silos are being broken up and knowledge is being gained by many.
Perhaps one could argue there is a difference between known & unknown technical debt. Perhaps one can assume given a reasonable number of automated tests that known technical debt could be estimated. There may be an assumption the amount of known debt is, er, “known” or finite.