Some of us have been there. Working on a software that dates back, 5, 7 or maybe even 10 years. It’s been given the unofficial label of being a “legacy” software application. But it still runs most of your business, so it's forbidden to use that word.

Those years of development have left it’s mark. It’s now a mix and mush of different architectural styles, big classes, some security issues and it's all coupled together.

It’s turned into a big ball of mud. An application that architects shun and try to avoid. Is it hopeless to untangle this mess? Maybe not. But maybe that’s not your biggest problem.

Maybe the problem you should be focusing on is the developers

They’re the ones who’ve been developing the application all these years. Development that's mostly guided by senior developers, because no architect wants to touch the application anymore.

Some have been there for many, many years now. They have a huge amount of domain knowledge and are invaluable as employees. Yet, they never saw the application turn into the ball of mud it is now.

Why? Did they not care what was happening? Did they not attempt to correct it before it was too late?

Maybe they just liked their position and pay checks too much to just let it run it’s course, because it was not their job to care. They were there to build features and put out fires when needed.

Management surely didn't care, because no one made an effort to bring this situation to light.

My experience

I’ve worked as an architect at a company like this. At the time I was too inexperienced in that role. But I had the passion for it, so I learned what it meant to work as a software architect. I studied for it for months. I learned a ton of new things. My learning potential skyrocketed.

But I failed to untangle that big ball of mud even a little bit. Why?

Because I was focusing on the wrong problem. I focused on the technical problems, instead of the people. The developers were the most important ball I should’ve helped untangle here.

I wish I would've realized that..

Still, let's not blame anyone

It is not my intention to point my fingers at anyone. This is more self reflection. I wish I would have been wiser at the time to identify the problem and approach management with what I had realized, so we could work the problem together.

Reflecting on my time there and continuing on my path to learning I’ve come to realize that there are standards of skill in development at some companies. Maybe more so at companies that have a separate technology department, and haven’t realized that the technology is at the core of that company. It’s just a separate department that's maybe 15-20% of the entire workforce.

The developers there might be on the older side of the age spectrum. More people are over 40 years old, than under. They seem to have lost their passion to learn and just want to maintain the status quo. So they’ve been continuing with their usual style of working for the past 3-6 years.

Creating a class after another in one single folder, that's now bloated to a massive scale. Not knowing about dependency injection which exists to introduce loose coupling into the system. Not focusing on modularity, but instead just refer to big classes that do all that work. Everything gets squeezed in nice and tight, into one big package that's deployed at once.

In any case, when the standard of development is low you need to focus on first uplifting the quality in every day development. Introduce people into the basic concepts, such as dependency injection, decoupling, modularity, SOLID principles. Teach them what software architecture is, what architectural qualities are, how to identify them and what to focus on when building new things, what modern things are out there.

As an architect, you are also a mentor. A teacher. And you must produce good quality code to set an example! Get your hands dirty like everyone else.

Also, teach people what business value it brings when you can build a system with good architectural qualities, modularity and good decoupling. That value doesn't have to be instantaneous. Most value is generated later down the line when talking about architectural decisions.

Once you have done this, and actually improved people's skill level, you can start introducing architectural decisions and changes.

Get the leadership on board

However, before you do anything, have your leadership or management sponsor your efforts. You will be shifting the focus away from technical problems, into solving the skill problems with people.

Otherwise you will end up like me. Having to face the push back of senior developers who don't want anything to change. Developers, who'd rather continue to rule over the application in the shadows, than actually claim accountability which results in decisions happening behind your back even though you're in charge of making those decisions. Working to tear down the changes you've made to improve the every day development quality because they don't understand them, instead of just saying that they don't so you can help them see the reasons.

When that happened I simply walked away. I didn’t have the leadership’s backing at that point because I was too inexperienced in office politics to realize I had to identify this issue and work on it, before I got to work on the technical stuff.

Final mentions

Many of us have a story like this. I consider myself lucky that this happened so early in my career and at a point in my career where I continue to learn at a somewhat extraordinary pace so now I see it as a learning opportunity. My skills skyrocketed, and that in turn helped find a new job. One that I'm very happy in.

This experience helped me grow a mile taller.

The inspiration to write this post came to me after I completed reading the "Fundamentals of Software Architecture, An Engineering Approach" by Mark Richards and Neal Ford. This book validated a lot my work as an architect. I was more interested in the definitions and expectations from a software architect, as well as the soft skills portion of the book, rather than the technical portions.

In any case, if you're an aspiring software architect, or one who still questions some of the work you do, I truly recommend you read it.