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.
In reply to Re^5: Beyond Agile: Subsidiarity as a Team and Software Design Principle
by chacham
in thread Beyond Agile: Subsidiarity as a Team and Software Design Principle
by einhverfr
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |