Your legacy software might not the problem. Maybe it’s the developers.

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.

Comments

[OssiDev]

Some notes to add:

• As an architect, soft skills and interpersonal skills are vital for you to succeed. All of your decisions are going to be challenged. People need to be convinced that your decisions are the right ones. However, if you have a cohort of people almost rebelling against your decisions and trying to tear them down one by one well after they've already been established, you need to have the management's support to enforce those decisions. Sometimes that cohort is led by one developer who's turning other people to his side. It sounds really childish, but that's how we human beings behave.
• If you have a lot of people trying to push back on your decision after they've been made, you can always supersede an earlier decision, but at that point you might want to circle back into asking the developers if they understood the decision and maybe in general, if they actually want a change. Management might be imposing that something needs to change, but developers haven't accepted that fact, so you should maybe hold a workshop to figure out if people want a change, what the pain points are, what we should focus on etc. This way you involve the people in the decision making and make sure they understand them. Maybe take one or two hours to educate people on the importance of software architecture and what it contains. This is useful if you're planning on making major changes and essentially trying to steer the ship into another direction.
• I personally don't like the idea of an "Architectural Review Board", or any type of oversight committee who sets the rules. Instead, work with the teams (or just one team). If you have multiple teams working on one product and you're supposed to be the software architect of that product, it's not a good idea to just be tied to one team because your influence will be limited.
• Office politics play their part in everything you do, because some people might have seniority in terms of experience at that company, while you may posses more technical skill. They can easily gain influence to challenge your decisions, even though you've proven your point from a technical and business points of view.
• There is another, slower way, to grow the technical skill level of the people in the technology department: hire skilled developers. Most likely though, high level developers will shy away from working at that company if they realize the product you're building is a big ball of mud, and sometimes you'll hit budgetary constraints that prevent you from paying what they're asking. So you're stuck with the skill you got.