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.
|
|---|
| 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 | |
by Your Mother (Archbishop) on Jul 30, 2015 at 20:18 UTC | |
by chacham (Prior) on Jul 31, 2015 at 12:36 UTC | |
by mr_mischief (Monsignor) on Jul 31, 2015 at 16:22 UTC | |
by chacham (Prior) on Jul 31, 2015 at 16:44 UTC | |
by mr_mischief (Monsignor) on Jul 31, 2015 at 16:52 UTC | |
|