An Architect’s Dilemna: Should I Rework or Exploit Legacy Architecture?

I recently spoke with an architect has been tuning up a legacy system that is built out of a patchwork quilt of technologies. As a consequence of its age and lack of common design approaches, the system is difficult to maintain. Error and event logs are written (in fact, many are), but they are inconsistent and scattered. It is extremely hard to collect data from and troubleshoot the system when things go wrong.

The architect has instigated many architectural improvements to this system, but one that to me was absolutely brilliant was to not insist that the system be reworked to use a single common logging mechanism. Instead, logs were redirected to a NoSQL database that could then be intelligently queried to troubleshoot problems as they arose.

Rather than dive in and “fix” legacy code to be consistent, this was a “splice and intelligently interpret” solution that had minimal impact on working code. Yet this fairly simple fix made the lives of those troubleshooting the system much easier. No longer did they have to dig through various logs by hand. They could stare and compare a stream of correlated event data.

Early in my career I was often frustrated by discrepancies in systems I worked on. I envisioned a better world where the design conventions were consistently followed. I took pride in cleaning up crufty code. And in the spirit of redesigning for that new, improved world, I’d fix any inconsistencies that were under my control.

At a large scale, my individual clean up efforts would be entirely impractical. Complex software isnâ’t the byproduct of a single mind. Often, it simply isn’t practical to rework large systems make things consistent. It is far easier to spot and fix system warts early in their life than later after myriad cowpaths have been paved and initial good design ideas have become warped and obsfucated. Making significant changes in legacy systems requires skill, tenacity, and courage. But sometimes you can avoid making significant changes if you twist the way you think about the problem.

If your infrastructure causes problems, find ways to fix it. Better yet (and here’s the twist): find ways to avoid or exploit its limitations. Solving a problem by avoiding major rework is equally as rewarding as cleaning up cruft. Even if it leaves a poor design intact. Such fixes breathe life into systems that by all measures should have been scrapped long ago. Fashioning fixes that don’t force the core of a fragile architecture to be revised is a real engineering accomplishment. In an ideal world I’d like time to clean up crufty systems and make them better. But not if I can get significant improvement with far less effort. Engineering, after all, is the art of making intelligent tradeoffs.

2 thoughts on “An Architect’s Dilemna: Should I Rework or Exploit Legacy Architecture?

  1. I see this very often in the wild. While as a software engineer I pride myself on architecturally inspired designs and implementations, when you’re not the only chef in the kitchen it is impractical to expect there to exist a single vision for how things are to be done. It’s hard enough keeping your own designs and implementations consistent over time, let alone expecting a distributed team do so also. So cruft is plentiful.

    One of the biggest challenges I see is that corporations care about little more than shipping code. While I agree that shipping code is job #1, there are many other important jobs (let’s call them job #2, #3 and #4) that, while important, are more often than not, neglected. Sadly, focusing solely on job #1 results in much accumulated technical debt which, over time, burdens the system and can ultimately prevent job #1 from being completed. So what to do? Well, you can achieve almost anything if you use enough duct tape! But that does not tickle the right part of my brain!

    So I know how it feels to want to land the plane, take it apart, and rebuild it piece by piece. But sadly that is never practical despite the obvious benefits. So we’re left with architecturally ugly solutions that are applied to keep the plane flying, regardless of the technical debt it might incur.

  2. Simon- I agree with your sentiments: an important (but often unstated) job of an architect should be to sustain the ability of the software system to adapt and grow.

    The architect whose story I was recounting was not making a duct tape solution in my opinion. Instead he made minimal changes to improve the system and left the inconsistent existing logging code intact. Not ideal, but not harmful, either. He didn’t increase the entropy of the system by his “fix”. When you can fix a problem this way, you are lucky. As a matter of principle, if you can shore up your architecture, make changes and enhancements, while continuing to encapsulate the poorly designed parts, you are doing OK.

    Too often, however, duct tape solutions are applied deep in the bowels of systems. As a consequence, code and data become even more tangled and incomprehensible. And it becomes increasingly difficult to make repairs or enhancements.

Leave a Reply

Your email address will not be published. Required fields are marked *