People have talked about it for years. Even if you're new, you've certainly been on the receiving end of more war stories than you care to remember; it's that old legacy system. You know, the one that started out small but now has all kinds functionality tacked on here or growing out of there. Corporate architects most certainly call this growth subsystems but you know better. It's really just the junk that's built up over time because the system was never refactored.

It's widely accepted that refactoring is a best practice for keeping code simple, DRY, and maintainable. What doesn't seem so widely accepted is the habit of applying the same practices at a broader system level.

Why don't we refactor systems? I started thinking about this very question during a recent all-day system design presentation, one of several in a series mind you. As I ingested slide after slide of barely visible text accompanied by Visio diagrams packed with boxes and arrows pointing in every direction, I wondered how things became so complicated.

In my experience, there seems to be some kind of stigma around reworking (aka refactoring) interconnected systems. New features are always bolted on to our existing systems, but nothing is ever redesigned, reorganized, or re-anything'ed. Over time, we end up with bolts on top of bolts until the thought of reworking any part of the system is completely overwhelming.

So why is the concept of refactoring an interconnected system so foreign when it's been used so successfully for more discrete pieces of software? Is it possible?