No Deadlines for You! Software Development Without Estimates, Specs, or Other Lies
How to write great software for pleased business owners without telling them how long it will take you to do just about anything
The article’s author suggests a new approach to software development that does not involve committing to estimates of how long a project will take. The method puts uncertainty and risk at the center of a conversation between the developers and the rest of the business, allowing the entire industry to tackle those genuine challenges together.
When an Important Person asks for an estimate, the author suggests using the opportunity to politely but ruthlessly interrogate them about the business and its challenges, risks, and goals. This will give the developer a better understanding of the central problem the company is facing and the words the Important Person uses when thinking about it.
This approach allows for a more effective solution to be developed instead of relying on traditional methods that often fail to deliver value and leave business people unhappy. The author also emphasizes the importance of understanding the business model, the motivations of customers, and the risks the leadership is worried about.
The author also explains that traditional methods like immediately trying to flesh out the spec in more detail, stalling, giving the spec a quick skim and listening to the seductive voice of System I, and pushing back aggressively, are all guaranteed to fail. These methods do not provide a solution that addresses the real problem that the business is facing, leading to ineffective software.
In conclusion, the author suggests a new approach to software development that involves putting uncertainty and risk at the center of a conversation between the developers and the rest of the business, allowing for a more effective solution to be developed. This approach requires the developer to better understand the company, its challenges, and its goals by interrogating the Important Person when an estimate is requested.
The author suggests that once the developer and the Important Person understand the central problem facing the overall business and how the proposed bit of development effort fits into a possible solution, they should wrap all that up and deliver it back, repeating as many of the words they used as possible. This shows that the developer is working with the Important Person to solve the actual problems the business is facing and has not promised any date by which the report will be finished. It also demonstrates that the developer is earning the Important Person’s trust.
The author also mentions that the developer may encounter a situation where the team doesn’t have enough information to make the call on the three-month deadline. In this case, the developer could tell the Important Person they don’t know. However, this doesn’t help the business solve its problem. The author suggests that instead of giving an uncertain answer, the developer should focus on obtaining more information to help them make the right decision and generate more value for the business.
The author emphasizes that acquiring information is often the best way to generate value in uncertainty. He suggests that the developer should pick the next thing to work on based on gathering as much information as possible about the things they are most uncertain about. He also advises reading Donald Reinertsen’s Principles of Product Development Flow for more details on this approach.
He concludes that by following this approach, the developer can write great software for pleased business owners without telling them how long it will take to do anything. The developer will be able to tackle real challenges together with the business instead of pretending that such nasty things don’t exist.
The author suggests that to write great software for pleased business owners without telling them how long it will take, developers should become a student of the overall business they are in, sequence their work to extract as much information from reality as early as possible and take risks and opportunities the centerpiece of an ongoing conversation with the rest of the business. This approach will allow developers to tackle uncertainties with the company and create a more satisfying way to work.
The author also recommends reading books and blog posts by experts in the field, such as Donald Reinertsen’s “Principles of Product Development Flow,” Eric Ries’s “The Lean Startup,” Kent Beck’s “Software Design Glossary” and “Extreme Programming Explained,” Douglas W. Hubbard’s “How to Measure Anything,” and Laura Klein’s “Users Know” and “UX for Lean Startups.” These resources will provide more information on generating value in extreme uncertainty conditions, handling complexity, and making better decisions.
The article is “No Deadlines for You! Software Development Without Estimates, Specs, or Other Lies.“