Why Young Software Projects Turn Legacy

Software should be matured by senior engineers, maintained by junior engineers; not other way around.

Important note: this article may seem to be written with a strong, upfront tone. While it may sound that I'm trying to confront somebody, this is rather a simple attempt to describe facts as they are and to suggest solutions to specific problems.

Common Problems of Software Projects

Without being shy, I consider myself being a senior level software engineer (I also do architecture, but we're talking about hands-on development skills). I often join mature but still young projects (1 to 3 years old) which suffer from common software diseases:

• Bad quality and too many defects,
• Incorrect architecture,
• Poor maintainability,
• Slow development pace.

After looking into the root cause of these problems, without exceptions, inception of the project is found guilty in all of them. It's like building a house on a corrupt foundation - it won't stand long.

Just like a house built on infected foundation, these projects seem to perform well in their early days, while being small and immature. That is true even if the development team consists of junior developers only. After all, building a house where nobody can really live is easier than building a full fledged living complex. That's why having just junior developers in the team often seems sufficient at the beginning. Once the size and complexity of the software approaches average (and sadly, even earlier), it starts to distort and shows signs of falling apart. That's when usually senior level engineers are brought into the project team to diagnose and cure the solution. 

The task given to senior engineers in such situations is not that easy, and unfortunately, often impossible. There are many technical, political, and ethical problems that we need to tackle to at least try the solution. Here are some of them:

• Software architecture is already chosen. Even though many people mistakenly think that such decisions can be made later on, it's literally impossible to replace one software architecture with another, without tearing the solution apart or rewriting it all over again. Architecture is a backbone of the solution, and just like a backbone of a human, it's there for a long time, and cannot be replaced just so.
• New feature development still needs to continue. While we are often demanded to rewrite the application, it often comes with such condition as "do it in small pieces only, not to disturb the new feature development". Well, then I'll tell you what - you have to live with the solution you have, probably forever. (Yes, it sounds sad. Especially so because I admire the willingness to fix things, at least later instead of never). But new features are being developed all the time. That makes the task impossible to achieve, because you may have a full development team pulling the solution into the old, incorrect direction, while couple of senior engineers are trying to fix it. So you've created a race condition with yourself. This can become a pump of resources and money very easily. If you have budget to enjoy this luxury, sure, go fo it. But just know what you are dealing with.
• Developers' resistance. Senior engineers often face a wall of resistance from the developers who started the project. Obviously, they know a lot about the current solution and the codebase, but that does not make them seniors (sorry guys). These developers (among them, especially opinionated ones) have hard time accepting the fact that somebody new to the team is claiming that something is wrong with the solution (after all, it worked so far). It takes good listening skills and strong ethics for them to be willing and go through the changes. Change management skills are not something that can be taught quickly, so this delays execution of changes as well.

Start with Seniors, Continue with Juniors

All problems can be avoided if you can simply start your project with senior engineers. They can build the right foundation and architecture from the beginning.

I understand that this means more money from the beginning, but the long term total can be less. To make things little bit easier, you can also mix junior and senior developers into the team. Let seniors rule the important decisions, while also training juniors. Eventually, when the time comes, you can decrease the number of seniors and increase the number of juniors. When all patterns, practices, and everyday processes are in place, project should be able to maintain the development pace even with well-trained juniors. Obviously, it requires strong commitment even from the junior developers to keep the process and patterns in place (that's why it's recommended to have at least one senior per team), but as long as that's achieved, there is much less to worry.

Caveats

I mentioned many little things that together make sense, but they come with conditions or caveats that you need to have in mind.

• What is Legacy? It's a software solution that can be compared to a weak, tired, or ill person. This is the software that has many problems, fixing which often reveal other problems. Working with such code has become slow and you receive much less new features for the same period of time. Legacy solution makes you feel that things are getting worse, not better.
• Who is Senior and who is Junior? You may know the meaning of these words, and you may have heard somebody claiming to be one or the other, but "all you hear is an opinion, all you see is a perception". You need to be sure that you are not mistaken about skills of the people, or even about your own skills. Equations written above are true only if both sides of the equation are taken as described. You won't believe how many developers I have met who claim they are seniors but I've assessed them as juniors. Matters get worse when developers strongly believe they are seniors - often there is no way you can convince them, unless you ask them to pass an interview of a real senior - which may not be an option with existing team members.

I'm not trying to say that junior engineers are anyhow worse or better than senior ones. Every senior engineer (including myself) has once been a junior. With this article, I'm trying to swap the things around. Instead of starting with juniors (usual case), try starting with seniors. Instead of calling seniors for help later on (usual case), bring in juniors at later project phases for cutting down your team costs. You should see strong benefits long run.

Finally, as I said above, we all once were juniors (and still are in specific fields). It's vital that you patiently help your engineers grow by enabling, mentoring, coaching, and training them (I can help train software engineers in various technical areas). This approach is the key to maximize your ROI and keep employee engagement and satisfaction at a maximum.

About Author and Content