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:

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:


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.



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

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

The author of the above content is Tengiz Tutisani.

If you agree with the provided thoughts and want to learn more, here are a couple of suggestions:

Ready to take the next step?

Let's Talk