Software development estimates are frequently *way* off
Software development estimates are frequently *way* off.
Why? Because many aspects of software development are nearly impossible to estimate.
Here are 9 reasons software development estimates fail:
👇
1. “Done” is debatable.
Aspects of acceptable quality like performance, code quality, security, accessibility, reusability, readability, and usability are hard to specify and quantify. This leads to time-consuming arguments and negotiations over when code is truly done.
2. Merge conflict overhead is unpredictable.
The frequency and complexity of conflicts varies based on team size, code coupling, ticket size, branching strategy, tech, and merge frequency.
3. Dev environment issues are unpredictable.
Examples include hardware issues, framework and library bugs, slow servers, service interruptions, internet problems, access control issues, third party outages, VPN issues.
4. Untestable code is hard to identify up front.
If a new feature interacts with code that isn’t friendly to testing, refactoring the code may be required. This is hard to detect up front when estimating effort.
5. Bad requirements are hard to detect early.
Incomplete, vague, conflicting, outdated, or incorrect requirements are often hard to detect until implementation, deploy, or usability testing.
6. Requirements are “lossy”.
No document or tool can convey ideas with perfect clarity. This leads to misunderstandings, time-consuming scope negotiations, and clarifications.
7. Developer velocity varies daily.
Developer effectiveness, and efficiency varies widely. It depends upon tech expertise, existing code quality, domain knowledge, competing priorities, dev environment stability, turnover, domain knowledge, sickness, time off, and more.
8. Communication overhead is dynamic and unpredictable.
Overhead varies based on team size, solution complexity, documentation needs, turnover, coupling, and approach.
Every extra human adds overhead that’s hard to quantify.
9. Cross-team dependencies reduce control and increase the risk of delays.
Cross-team projects require multiple teams to deliver on time. That’s hard to do given all the previous variables listed above.
In summary, this is why I avoid fixed bid development projects.
Fixed bids presume predictability, autonomy, certainty, and control that rarely exist in the world of custom software development.