Software estimates have never worked and never will
David Heinemeier Hansson argues that traditional software estimation fails for complex projects, advocating a budget-based approach for flexibility and better outcomes, emphasizing trade-offs and adjustments during development.
Read original article
David Heinemeier Hansson argues that software estimation has consistently failed since the inception of computing, particularly for medium to large projects. He contends that as software development becomes routine, it transitions into products or services that can be purchased rather than built. Most software development today focuses on novel work, which is inherently unpredictable, making upfront specifications ineffective. Past attempts to define novel work have often resulted in solutions that do not address real problems, leading to a cycle of misdirection and rework. Hansson advocates for abandoning traditional estimation methods in favor of a budget-based approach, as outlined in his Shape Up methodology. This method allows for flexibility and negotiation during development, enabling programmers to deliver quality software on time. He emphasizes that successful software development relies on making trade-offs and adjustments throughout the process, rather than adhering to rigid estimates. This philosophy has been instrumental in the success of his company, 37signals, and can lead to better outcomes in software projects.
- Software estimation has historically failed, especially for complex projects.
- The shift from building to buying software reflects the challenges of estimating novel work.
- Traditional methods often lead to solutions that do not meet actual needs.
- A budget-based approach allows for flexibility and better project outcomes.
- Successful software development involves trade-offs and ongoing adjustments.
Related
Projects considered harmful – Part 1
Software development projects often prioritize time and budget over quality, leading to compromised dependability. Project managers focus on meeting objectives, neglecting software quality. Reevaluating project management practices is crucial for software dependability.
Fear of over-engineering has killed engineering altogether
The article critiques the tech industry's focus on speed over engineering rigor, advocating for "Napkin Math" and Fermi problems to improve decision-making and project outcomes through basic calculations.
Algorithms We Develop Software By
The article explores software development methodologies that improve coding efficiency, emphasizing daily feature work, code rewriting, the "gun to the head" heuristic, and effective navigation of problem spaces.
Software estimates have never worked and never will
David Heinemeier Hansson argues that software estimation has failed for medium to large projects due to unclear requirements, advocating for a budget-based approach that allows flexibility and adaptability in development.
Software estimates have never worked and never will
David Heinemeier Hansson argues that traditional software estimation fails for medium to large projects, advocating for a budget-based approach that allows flexibility and trade-offs for better software delivery.
2 comments"You can fix a feature list, or you can fix a date, but not both."
When doing estimates now I use the above mantra a lot.
Usually I pick a date for incremental updates. I find that more useful to people. But people asking before that date "what's in it?" seem somewhat bemused when I say '"I don't know".
For new projects we're more likely to pick a minimal feature set, but that causes some stress up the management chain who can see "progress" but can't yet see a finishing line.
[1]https://herbsutter.com/2019/07/13/draft-faq-why-does-the-c-s...
Back in 2019, I estimated a project to move a product to the cloud so that we could scale it out and make it more reliable. The business was projecting big growth, the existing system required daily baby sitting, and there were features that just didn't work because of poor software engineering. At the time, I barely had any cloud experience, hadn't used Python/R/Docker for very long, and didn't understand the product or business in depth. And yet, I was the most knowledgeable person on the team.
I estimated the project would take me 2 years. The project manager didn't like that. Behind closed doors they talked to my manager who told them 6 months was fine. They didn't talk to me about the team, the scope, the approach, nothing. The project got the green light and I was given 2 fresh grads - one who was awesome and one who wasn't.
Cut to a year later and we're spot-on my estimate, half way. We've delivered the major features and stabilized the product. It scales perfectly and is far below operational budget. Yet people are angry because it was sold as a 6 month project to middle management. The product was worth $10s of millions annually to the company. They're fretting over a couple $100k that they would have spent anyway.
But they didn't respect me or understand why it was 2 years. They could have talked to me about alternative approaches (maybe a lift and shift but I was strongly opposed). They could have asked me what sort of team could have done it faster (4 senior, motivated, knowledgeable, responsible engineers).
Related
Projects considered harmful – Part 1
Software development projects often prioritize time and budget over quality, leading to compromised dependability. Project managers focus on meeting objectives, neglecting software quality. Reevaluating project management practices is crucial for software dependability.
Fear of over-engineering has killed engineering altogether
The article critiques the tech industry's focus on speed over engineering rigor, advocating for "Napkin Math" and Fermi problems to improve decision-making and project outcomes through basic calculations.
Algorithms We Develop Software By
The article explores software development methodologies that improve coding efficiency, emphasizing daily feature work, code rewriting, the "gun to the head" heuristic, and effective navigation of problem spaces.
Software estimates have never worked and never will
David Heinemeier Hansson argues that software estimation has failed for medium to large projects due to unclear requirements, advocating for a budget-based approach that allows flexibility and adaptability in development.
Software estimates have never worked and never will
David Heinemeier Hansson argues that traditional software estimation fails for medium to large projects, advocating for a budget-based approach that allows flexibility and trade-offs for better software delivery.