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

The requirements are what they are. In general, it is not a wishlist, rather, a specific problem or situation arises that requires resolution. Usually, that does not change.

The above sounds much like someone who's never written business software that handles any sort of legally regulated process, anything covering policy issues at a large company, or anything that interfaces with third-party software. Tax codes change. Building codes change. Profit, loss, and expense reporting policies change. Configuration file formats change. The APIs of other packages change. Data interchange formats change. Acceptable cipher suites change.

There are only two types of software that never change once written. One is software discarded because it didn't meet the original need sufficiently. The other is software that is obsoleted because it didn't support the changes around it and wasn't considered worth updating. If you want to write software that never changes then basically your goal is to write software that fails. What kind of goal is that?

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

Replies are listed 'Best First'.
Re^5: Beyond Agile: Subsidiarity as a Team and Software Design Principle
by chacham (Prior) on Jul 30, 2015 at 14:04 UTC

    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.

[reply]

      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.

[reply]

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

[reply]

        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.

[reply]

In Section Meditations