Trail of tears architecture anti-pattern

I'm currently struggling with another project suffering from what I dub the "Trail of Tears" architecture pattern. This is a situation where the architecture is littered with the remains of legacy code that never seems to get removed. This leads to mounting maintenance costs, and a fragile architecture that becomes increasingly difficult to manage. It also has the side effect of creating a "broken window" problem where there is no clear "correct" way to do things and the necessary rigor around adhering to standards and best practices (I HATE that term...but oh well) rapidly falls apart.

Historically, the only way I've seen to combat this is to rigorously support opportunistic refactoring other wise known as following the "Boy Scout Rule". While this has it's own problems (folks breaking seemingly unrelated things trying to clean things up and inflated scope for features being two key ones) it has proven to be the only way to combat this problem.

The rub in solving this problem is that it necessarily forces a tempo drop when changing directions as we must now account for refactoring "things that work" so that they meet the new standards and patterns as they evolve. This is unfortunate, but trust me...it's absolutely necessary if you want a maintainable and healthy system running for years to come. My advice...don't walk the trail of tears.

Comments

Popular posts from this blog

Push versus pull deployment models

the myth of asynchronous JDBC

Installing virtualbox guest additions on Centos 7 minimal image