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

[mr_mischief]

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?