It’s 2 weeks to the day since I stood up in front of just over 30 people to lead my session When Good Architecture Goes Bad at the ACCU conference.

My plan was to present some examples of architectural decay, to collect some examples from the participants and to explore how things could be improved. I was particularly interested in the value and cost of work done to prevent architectural decay. It seems that developers agree that preventing such decay is a good thing but I was hoping to collect some examples that could make the financial side of things a little clearer as it seems to me that there is a disconnect between developers and managers in this area. It wasn’t too clear from the session description in the programme that this would be a workshop so first up I offered anyone who just wanted to sit and listen the chance to leave the room - there were no takers…

After a few introductory slides the first exercise asked participants to discuss examples of architectural decay from their real-life experience. I collected these on a flipchart:

Examples of architectural decay

• A single class used as a dumping ground
• Cancerous wart – ever increasing coupling between modules, packages etc.
• The number of programming languages used on the project increasing over time
• New interfaces added over time, but old interfaces still maintained (and never deprecated)
• Lots of code clones  (copies and near-identical copies)

I then presented some examples of architectural smells (problems in package/class/subsystem/layer relationships, overgeneralization etc.) and whiffs (subtle smells) e.g. no one on the team can tell you what the intended architecture is, time to implement changes increases etc.). The second exercise asked the group to come up with their own examples:

Architectural smells associated with these (and other) examples:

• Mismatch between documentation and software, mismatch between comments and code
• No clear responsibility for the architecture
• Implementation = specification
• Use of a proprietary language compiler
• Pile of s**t from the start of the project
• Clone and own as the main way of doing reuse
• Insufficient decomposition
• Knowledge of architecture held by a decreasing number of people

The bulk of the session was taken up by two case studies. In Case Study 1 an outsourced project had run into problems over a period of years. The company detected a considerable decrease in productivity over this time and the participants were asked to decide whether architectural decay could have caused the decrease in productivity and what they thought of the company’s proposed solution. (If you’re want to try this at home first you can download it as Software Architecture Decay Case Study 1 (PDF) from the Software Acumen web site.)

Participants’ observations included:

• Communication needed to maintain architecture
• Management needed to maintain architecture
• Someone required to shepherd the new team before they can get going
• Insufficient knowledge transfer process when software first outsourced.
• Team selection is important when assigning new roles.
• Unclear when productivity decline happened. Why didn’t company pick it up sooner?
• Who owned the software & the architecture – tests.

A second case study looked at a situation where a software system had been developed in 3 separate sites but the company had just closed two of the sites. Participants were asked whether moving maintenance to a single team at one site would cause the software architecture to decay. (Again, if you’re want to try this at home first you can download it as Software Architecture Decay Case Study 2 (PDF) from the Software Acumen web site.)

This time participants’ observations included:

• Fewer people, resourcing could contribute to decay
• Knowledge transfer / must learn new bits - again could cause problems
• Subtle differences between architectures of the different parts could cause problems - initially it’s a comprehension task
• Domain expertise was lost when two sites closed - could indicate significant loss of architectural knowledge
• What were the future plans - is there an implied refactoring?
• This situation needs management to go into the project with open eyes - non one was convinced this was the case
• There might be an urge to change the architecture which could be risky
• Not-invented here / cultural differences could lead to problems
• The motivation of the new team was questioned, skills drain could occur
• What was the background motivation for the change? This could set the tone for future work.

I then asked participants to travel back in time and come up with some ideas for maintaining architectural integrity in their previously noted problem projects:

• Encourage people not to do clone and own – but how to do this?
• Change the development process (again how viable is this, would management back it?)
• Embed a culture of refactoring (again but what if management won’t allow it?)(and note - some developers may want too much refactoring, be too keen to rewrite)
• Visualize the technical debt – detect architectural decay using tools
• Make responsibilities clearer.
• Add automated (architectural) checks.
• Cancel the project (earlier).
• Rewrite (earlier)
• Kill the architect (as noted by SPA 2008 participants also)
• Spread architectural knowledge.
• Spread the architectural work.
• Have frequent communication between whole group – up to three times a day.

The session covered some of the same ground as Tom Gilb’s keynote ‘Agile Methods Lack result management’, Steve Love’s session on ‘Snowflakes as architecture’ and (it later emerged) Dirk Haun’s session ‘Rewriting not recommended’.

Slides for the session area available at When Good Architecture Goes Bad (PDF).