What happens when the project that suits Agile in development finishes development cycles, enters support cycles and becomes a critical piece of software with few changing requirements and junior developers? The software was built in the first place to withstand the pace of a team of senior developers adding features, ripping out features - a flexibility built into the team's way of implementing the software that could not be maintained by the latter team. The latter team does not know how to change the software and dares not due to the complexity that was slowly built and understood in great detail by the former team. When changes need to be made to the underlying infrastructure, they require much more effort.
Agile home ground:[14]
- Low criticality
- Senior developers
- Requirements change often
- Small number of developers
- Culture that thrives on chaos
- High criticality
- Junior developers
- Requirements do not change often
- Large number of developers
- Culture that demands order
http://www.agile-process.org/change.html
Berry Boehm found that as software proceeded through its life cycle the cost of making a change became larger. Ratios of 100:1 for making a change after delivery versus project start are common. But ratios as low as 5:1 can be found. How flat this curve stays depends on many individual project factors.
There are three life cycle events that seem to accelerate software rot.
- When we proclaim the design is done and accept no more changes.
- When we move the system into maintenance and change the team's process.
- Last when the cost of making vital changes exceeds our resources we reach the wall of unmaintainability.
