4 ms·

Sure, waterfall might work for very small fixed contexts. Control software for a spacecraft is a great example. I can sit down now and start designing software

Sure, waterfall might work for very small fixed contexts. Control software for a spacecraft is a great example. I can sit down now and start designing software to do physical calculations for a system that won't ship for 7+ years, confident the laws of physics won't change in that time. In fact, NASA did this in the Apollo program. Most software is used by customers with changing needs and competitive pulls. I've built software in the last 2 years that we would have taken a radically different approach to if LLMs were available, because they're great at summarising natural language. But they weren't. Imagine if we'd been building something for 2 years and never learned anything about changing technology or customer expectations - instead we shipped something fast, and then looked back after we learned about new things and made it better. That's how the World should work, and why software is not like building a bridge or a house or basically anything else in the history of engineering. As to your specific exampleS: I have some detailed knowledge of hospital EHR systems, and they are so massively, hilariously broken in ways that modern software practices could easily help address. I suggest reading Accelerate [1] for data and examples of how agile applied to DevOps practice in particular means you can be more responsive and produce safer software, especially in that context. I, like you, also prefer software for stuff that matters. I've been trained in formal methods, I've done embedded systems development, I've worked in medical/healthcare contexts. Your statement that what I've written above does not apply to those environments (including the use of formal verification methods), doesn't make sense to me. [1] https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339/ref=sr_1_1 https://www.amazon.com/Accelerate-Software-Performing-Techno...

belter 2y ago
Agile advocates love to contrast their approach with Waterfall, which contrary to Agile folklore, was neither rigid nor uniformly applied. Let's review the Agile Manifest from the perspective of delivering Software That Matters, that I define as Software where failures can cause significant loss of Lives, Money, or Reputation: 1. Early and Continuous Delivery Speed over quality in critical software contexts invites catastrophic failures. Instead just implement phased delivery schedules that prioritize comprehensive testing and stability over speed, ensuring system reliability. 2. Welcoming Late Changes This flexibility often leads to scope creep and consequential delays, undermining system integrity. Instead have a change control board to rigorously evaluate the implications of proposed changes, safeguarding project stability. 3. Frequent Software Releases Regular release demands degrade software quality and exhaust development teams, detracting from critical system safety. Instead base your release schedules on thorough testing and feature completion, ensuring each release enhances system robustness. 4. Daily Business-Developer Interaction Frequent meetings disrupt productivity and can force development compromises, jeopardizing precise project requirements. Instead opt for structured weekly updates and essential communication to maintain clarity and focus without sacrificing project integrity. 5. Trusting Motivated Individuals Sole reliance on individual motivation without structured oversight introduces risks of inconsistent quality in high-stakes projects. Instead clearly define roles and accountability metrics, aligning individual contributions directly with critical project outcomes. 6. Face-to-Face Communication This traditional communication mode fails to accommodate remote participants or ensure accurate documentation of critical decisions. Instead leverage advanced digital communication tools that enhance documentation, suitable for modern, distributed teams. 7. Working Software as Progress Measure Focusing solely on functional completions neglects essential aspects like security, scalability, and user experience. Instead expand progress indicators to include comprehensive evaluations of non-functional requirements, providing a holistic view of system health. 8. Sustainable Development Pace The ideal of an unvarying pace is impractical under the variable pressures of high-stakes software development. Instead adopt development rhythms to real-world project dynamics, accommodating natural workflow variations to prevent burnout and ensure quality. 9. Continuous Technical Excellence An unrelenting pursuit of technical perfection can obstruct pragmatic and timely deliverables in critical scenarios. Instead aim for pragmatically viable solutions that meet current needs with provisions for iterative enhancements as future requirements evolve. 10. Maximizing Work Not Done Striving for minimalism can neglect essential complexities, endangering the whole system. Instead prioritize a thorough approach that covers all necessary bases, balancing simplicity with comprehensive risk management. 11. Self-Organizing Teams Teams without structured guidance can diverge from critical safety and performance standards. Instead implement a framework that offers direction and support, ensuring teams adhere to best practices essential for system reliability. 12. Regular Reflection and Adjustment Constant reassessment cycles can disrupt ongoing projects and dilute focus on strategic goals. Instead space out reflective practices to better assess their impact and refine processes without compromising ongoing project stability.
- PaulRobinson 2y ago
  OK, so this is getting contentious, but it seems to me you're not up to speed with industry studies. Every study of continuous delivery suggests it improves quality by finding bugs earlier (because it has continuous integration - automated and rigorous testing to help identify unintended regressions - as a dependency), and reducing MTTR when undetected bugs do occur, because releasing fixes is quick and standardised. I'll refer you to the book in my comment above which demonstrates this with data collected from thousands of companies. If you don't understand the reasons behind this, you're not going to understand why any of the other things lead to safer software, released earlier, and producing more value in the short, medium and long terms. So we should stop here. I'd strongly encourage you to start by reading Accelerate and then come back and take another swing at it if you want, but given your current perspective - which sounds highly authoritarian, cynical, and divorced from data collected over a wide range of industry contexts - there's no point in us discussing this further.

belter 2y ago

Agile advocates love to contrast their approach with Waterfall, which contrary to Agile folklore, was neither rigid nor uniformly applied. Let's review the Agile Manifest from the perspective of delivering Software That Matters, that I define as Software where failures can cause significant loss of Lives, Money, or Reputation: 1. Early and Continuous Delivery Speed over quality in critical software contexts invites catastrophic failures. Instead just implement phased delivery schedules that prioritize comprehensive testing and stability over speed, ensuring system reliability. 2. Welcoming Late Changes This flexibility often leads to scope creep and consequential delays, undermining system integrity. Instead have a change control board to rigorously evaluate the implications of proposed changes, safeguarding project stability. 3. Frequent Software Releases Regular release demands degrade software quality and exhaust development teams, detracting from critical system safety. Instead base your release schedules on thorough testing and feature completion, ensuring each release enhances system robustness. 4. Daily Business-Developer Interaction Frequent meetings disrupt productivity and can force development compromises, jeopardizing precise project requirements. Instead opt for structured weekly updates and essential communication to maintain clarity and focus without sacrificing project integrity. 5. Trusting Motivated Individuals Sole reliance on individual motivation without structured oversight introduces risks of inconsistent quality in high-stakes projects. Instead clearly define roles and accountability metrics, aligning individual contributions directly with critical project outcomes. 6. Face-to-Face Communication This traditional communication mode fails to accommodate remote participants or ensure accurate documentation of critical decisions. Instead leverage advanced digital communication tools that enhance documentation, suitable for modern, distributed teams. 7. Working Software as Progress Measure Focusing solely on functional completions neglects essential aspects like security, scalability, and user experience. Instead expand progress indicators to include comprehensive evaluations of non-functional requirements, providing a holistic view of system health. 8. Sustainable Development Pace The ideal of an unvarying pace is impractical under the variable pressures of high-stakes software development. Instead adopt development rhythms to real-world project dynamics, accommodating natural workflow variations to prevent burnout and ensure quality. 9. Continuous Technical Excellence An unrelenting pursuit of technical perfection can obstruct pragmatic and timely deliverables in critical scenarios. Instead aim for pragmatically viable solutions that meet current needs with provisions for iterative enhancements as future requirements evolve. 10. Maximizing Work Not Done Striving for minimalism can neglect essential complexities, endangering the whole system. Instead prioritize a thorough approach that covers all necessary bases, balancing simplicity with comprehensive risk management. 11. Self-Organizing Teams Teams without structured guidance can diverge from critical safety and performance standards. Instead implement a framework that offers direction and support, ensuring teams adhere to best practices essential for system reliability. 12. Regular Reflection and Adjustment Constant reassessment cycles can disrupt ongoing projects and dilute focus on strategic goals. Instead space out reflective practices to better assess their impact and refine processes without compromising ongoing project stability.

PaulRobinson 2y ago
OK, so this is getting contentious, but it seems to me you're not up to speed with industry studies. Every study of continuous delivery suggests it improves quality by finding bugs earlier (because it has continuous integration - automated and rigorous testing to help identify unintended regressions - as a dependency), and reducing MTTR when undetected bugs do occur, because releasing fixes is quick and standardised. I'll refer you to the book in my comment above which demonstrates this with data collected from thousands of companies. If you don't understand the reasons behind this, you're not going to understand why any of the other things lead to safer software, released earlier, and producing more value in the short, medium and long terms. So we should stop here. I'd strongly encourage you to start by reading Accelerate and then come back and take another swing at it if you want, but given your current perspective - which sounds highly authoritarian, cynical, and divorced from data collected over a wide range of industry contexts - there's no point in us discussing this further.