in reply to Re^6: Beyond Agile: Subsidiarity as a Team and Software Design Principle
in thread Beyond Agile: Subsidiarity as a Team and Software Design Principle

going from remitting information in form ICD-9 to form ICD-10

And Agile would have helped there? This has nothing to do with initial requirements during the design and coding phases which were implemented decades ago. New version, new requirements.

should have foreseen the need to switch from a few hundred simple condition codes to several thousand codes

As a side point, that one at least, is trivial.

  • Comment on Re^7: Beyond Agile: Subsidiarity as a Team and Software Design Principle

Replies are listed 'Best First'.
Re^8: Beyond Agile: Subsidiarity as a Team and Software Design Principle
by mr_mischief (Monsignor) on Jul 31, 2015 at 16:22 UTC
    New version, new requirements.

    So you're saying you would throw away the entire existing code base with all the business logic to write a new version from scratch using Waterfall? All because the data interchange format is more complex?

[reply]

      Huh?

      I think we're mixing up the tangent with the main discussion. The context is Waterfall vs Agile, specifically, quick releases. It was objected that requirements can and do change in unforeseeable ways and an example was proffered. I challenged the relevance of the example as the significant change happened long after the original design, to the point where it was not relevant to the method used for the original design process.

[reply]

        Who cares about the original design process? That code is written. You're advocating Waterfall. How would Waterfall be used to make the new version with the new requirements, given that there's already the existing code of the old version? What advantages would it give over one of the agile methodologies to get from the old version to the new version?

        Waterfall is a process designed to go from a blank slate to a finished product. Would you start from scratch, throwing away the old code? Would you try digging out the original design documents (which are not necessarily decades old) and altering them via some Waterfall process that now accounts for modifying existing code that was fully designed from the outset into a largely but not entirely new codebase?

        Or maybe you'd refactor pieces of the existing code, one after another, and test to make sure parts of the new functionality work as those parts are done every week or three?

[reply]

In Section Meditations