Ingmar Kellner presented some tips how to prevent your architecture rotting into a mess. When that happens, you will have these problems:
- Rigidity – The system is hard to change because every change forces many other changes.
- Fragility – Changes cause the system to break in conceptually unrelated places.
- Immobility – It’s hard to disentangle the system into reusable components.
- Viscosity – Doing things right is harder than doing things wrong.
- Opacity – It is hard to read and understand. It does not express its intent well.
According to Tom DeMarco, your ability to manage this depends on control. And control depends on measurements – if you can’t measure something, you can’t control it.
How rotten is your software? Look for cycle groups (some package X depends on Y depends on Z depends on A depends on X):
- They tend to stay
- They tend to grow
- They are a strong smell
Ingmar showed some examples in the JDK 6 (lots of cycles) and ActiveMQ (lots of cycles in 4.x, much better in 5.0 but again growing since then).
What can you do?
Use a consistent “architecture blueprint” that makes it obvious which layer/slice can use what. In the blueprint, layers are horizontal (presentation, domain, persistence) and slices are vertical (everything related to contracts, customers, users, and finally common code).
You will need someone with the role “Architect” who “defines the architecture, thresholds for coding metrics, identifies ‘hot spots'” and developers who “implement use cases, respecting the architecture and coding metrics thresholds.” All this is verified by a CI server.
At the same time, avoid “rulitis” – the false belief that more and stricter rules makes things “better.”
Some rules you might want to use:
- The blueprint is free of cycles
- Package naming convention that matches the blueprint
- Control coupling and cycles with tools
- Use tools to control code duplication, file size, cyclomatic complexity, number of classes per package, etc.
- Reserve 20% of your time for refactoring
Following these rules can help to reduce costs during the maintenance phase:
- 50% less time
- 50% of the budget
- 85% less defects
according to a study conducted by Barry M. Horowitz for the Department of Defense.
Dark Views 