I ran my workshop When Good Architecture Went Bad again at this week’s Software Architect 2008 conference. The session drew just under 40 participants which was very satisfactory from my point of view.

Regular readers will know that the session covers common patterns of architectural decay and gives some tips on how to address such decay.

I’ve previously run the session at SPA 2008, ACCU 2008 and as a straight talk at May’s Embedded Masterclass events. Each time there’s no shortage of participants willing to share their architectural horror stories and yesterday’s session was no exception…

The examples I collected included:

• A software system where the threading architecture decayed so badly over time that the system became unmaintainable and had to be scrapped.
• A couple of examples of business logic (with associated SQL) being captured in the software’s presentation layer – making it hard to replace this layer.
• An example of a software package that became so big it couldn’t be understood by one person and so became really hard to maintain.
• A software system whose architecture had to be seriously bent in order to meet performance targets.
• Software with a large number of cyclic dependencies that ended up as brittle spaghetti code.
• Several examples of drive-by programming – team-membership constantly changing, programmers not understanding architecture and so making mistakes when they code and then moving on.
• One example of drive-by-architecting with similar consequences.
• Problems with obsolete software and hardware technology, lack of skills in these obsolete technologies leading to decay.
• A couple of examples of over-engineered (gold-plated) software modules.
• Sales-driven evolution – where there is no clear roadmap or scope for the software system and so the implemented software architecture inevitably diverges from the intended architecture.
• Lack of architectural direction – no one responsible for laying out an architectural vision, see related point on sales-driven evolution.
• Software that is bloated with technologies – new technologies e.g. web communication technologies being added without obsoleting older technologies.
• A big example where an outsourcer implemented everything in a software system rather than buying in some best-of-breed components. It was a good system but this example of not-invented here led to a huge software base that in the end couldn’t be maintained by the outsourcer or the customer due to lack of resources and skills.
• Merged companies with different cultures and different principles having to collaborate on a software system leading to decay.
• Uncontrolled code use – programmers grabbing code, classes and even variables from other parts of the software without any control on what could and couldn’t be used – once again led to an unmanageable code base.
• New people coming into the team and adding untested technologies to the software in an uncontrolled manner.

You can see reports on the previous deliveries of the workshop here: When Good Architecture Went Bad at ACCU 2008 and here: Architectural Decay at the Embedded Masterclass.