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

he above sounds much like someone who's never written business software that handles any sort of legally regulated process

One project i was on was to enforce the rules of internal security and audits on ~8,000 servers and clients (iiuc, at least twice that now.) To address this, and to support changing rules and system administrator preferences, the client itself was designed with different types of enforcements, but the actual rules were sent to the clients in a separate file. Luckily, we got to do it in Perl.

There, forethought was used to design to address anticipated changes. I have worked with him many times, and have seen that he always uses that approach, that is, to expect change.

Other people approach things by designing software to the specifics of the request (as opposed to designing toward the underlying issue.) Although i believe this approach to be fundamentally flawed, that's just my opinion. Regardless, Agile will definitely help them.

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

Replies are listed 'Best First'.
Re^6: Beyond Agile: Subsidiarity as a Team and Software Design Principle
by mr_mischief (Monsignor) on Jul 30, 2015 at 19:45 UTC

    So what you're saying is that projects such as going from remitting information in form ICD-9 to form ICD-10 in the healthcare and health insurance industry in the US should have involved no programming at all, because software developers should have foreseen the need to switch from a few hundred simple condition codes to several thousand codes in a new recursive data format? A new data format whose printed specification manual is over five inches thick and costs $1500?

    If you're handling changes like that in a basic configuration file, then your powers of foresight are far beyond anyone in the entire healthcare industry. It was a months-long project most places to handle the new standard properly.

      ++ just for mentioning ICD10. Bitten by turtle, spacecraft injury, injured at prison swimming pool... the most amusing of the boondoggles so far.

      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.

        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?