The rewarded hero and the architect who never pays the price

Did you ever wonder why so many systems eventually become legacy systems?

This question has always been particularly interesting to me because modernizing such systems - by improving their architecture, development processes, and ways of working - has been my passion for many years.

Why is this question so interesting?

I don't know a single architect or engineer who started their work and consciously decided to make the worst possible decisions so that their future selves or colleagues would suffer years later. Quite the opposite. Most (all?) of the people I know do their best to ensure that the solutions they build and design will remain easy to work with for years and will evolve smoothly as new requirements emerge.

And yet, despite such a positive attitude, so many efforts fail.

I have two theories that help explain why. They don't contradict each other - they simply focus on two different scenarios.

Theory of the Rewarded Hero

We have an amazing engineer on the team. They know the domain inside out and understand exactly how the software works and how it was built. They can easily explain the mysteries of the codebase, navigate architectural coupling, and guide others through it. On top of that, they are always willing to help during a crisis. Whenever there's a production emergency, they jump in, and they somehow manage to solve problems nobody else can.

After some time, when there is a need to build something new, a system or a service, their managers and technical leaders decide that this person should lead the effort. After all, they have already demonstrated deep domain knowledge, technical expertise, and dedication.

It seems fair. It also seems like a good plan. And unfortunately, far too often, it isn't. Why?

Because all of the characteristics above, impressive as they are, are not necessarily the characteristics of someone who knows how to design a maintainable system. Those qualities are valuable, but domain expertise and technical knowledge alone do not mean someone understands what good architecture looks like or how to balance competing trade-offs.

Additionally, if someone has been a hero for a very long time, it should make you wonder: what improvements were never made? After all, a hero needs a fire to fight.

And don't get me wrong. I'm not saying anyone intentionally avoids improvements. I'm simply saying they may not know how to recognize certain problems or how to address them. If the system they have worked on for years has not significantly improved, why would you assume the next one will be different?

Often, these people genuinely do their best to create the new system or service in a better way. Yet without the necessary architectural knowledge, experience, and skills, their chances of succeeding are much lower than most people assume.

Theory of the Architect Who Never Pays the Price

The second theory is about someone who believes they know how to design systems. They have knowledge and experience, understand patterns, and know how to communicate ideas, convince others, and inspire teams.

They lead the work, everything goes well, and people start using the system. Then, slowly, things begin to deteriorate. Eventually, working with the system requires a major modernization effort or the organization simply accepts a significant decline in delivery speed.

But by then, the architect is no longer there. They have already left the project or perhaps the company, and moved on before experiencing the consequences of the decisions they made.

And the cycle repeats in the next project.

Of course, I am not suggesting any bad intentions. The problem is often much simpler. They possess a lot of knowledge that has never been battle-tested. On paper, it looks convincing and initially appears successful, but it cannot survive contact with reality.

The challenge is that reality delivers its verdict long after they are gone, leaving no opportunity to learn from the outcome.

Maintainability Is a Separate Skill

One assumption hidden behind both theories is that maintainability expertise is a separate skill. Being a great engineer does not automatically make someone a great architect. In the same way, being a great architect does not automatically mean someone knows how to build systems that remain easy to evolve for years.

Maintainability requires a different kind of experience.

You need to see systems after years of growth. You need to observe how today's shortcuts become tomorrow's constraints. You need to experience the consequences of coupling, misplaced boundaries, premature abstractions, and architectural decisions that looked perfectly reasonable when they were made.

The challenge is that this knowledge is difficult to acquire. The feedback loop is long, and many people move to another project before they can see the results of their decisions. As a consequence, they keep accumulating knowledge about how to build systems, but not necessarily about how to keep them maintainable.

This is why deep domain expertise, technical excellence, leadership skills, or architectural knowledge alone are not enough. They are all valuable, but maintainability requires learning a separate set of lessons - lessons that only become visible with time and experience.

Theories and the Feedback Loop

There is one problem shared by both theories: the distance between decisions and consequences.

Until now, it could take years before the cost of a poor decision became impossible to ignore. Because of that delay, even people who are aware of the scenarios described above often struggle to connect today's problems with decisions made long ago.

The feedback loop is simply too long.

How AI Can Help Produce Less Legacy

With the increased pace of software delivery, the feedback loop is becoming much shorter. And I believe this is the aspect of AI that can genuinely help us reduce the amount of legacy we create.

Not because AI is exceptionally clever. But because it will bring the pain much earlier. And pain is one of the most effective teachers we have.

When consequences appear sooner, they are easier to connect with the decisions that caused them. The problems are also less entangled with years of additional complexity, making them easier to understand and correct.

This creates an opportunity for our industry to produce fewer legacy systems and learn, collectively, how to build software that remains maintainable for decades.

It is also a great opportunity for people involved in architectural decisions to see the real impact of those decisions while they still have time to learn from them. Some will discover how to avoid similar mistakes in the future. Others may realize that this particular aspect of engineering is simply not for them.

Summary

Most legacy systems are not created by people who do not care. They are created by capable and well-intentioned professionals who either lack maintainability expertise or never stay long enough to experience the consequences of their decisions.

The common challenge behind both scenarios is the feedback loop. When it takes years for architectural mistakes to reveal themselves, learning becomes difficult.

This is why the accelerated pace of software development enabled by AI may become an opportunity. Not because AI will design better systems for us, but because it may expose the consequences of our decisions much sooner, allowing us to learn faster and create less legacy in the process.