The Right Attitude to Deal with Legacy Code

If you’re like the majority of software developers working for a company, you probably have to deal with legacy code, at least sometimes. Well maybe you don’t because you’re working on a brand new project with few people. But chances are you do.

I for sure have faced legacy code. Many times, and coming in various flavours. And I know quite a few people that have, too. Over the years I’ve had the time to experience how it feels to work with legacy code, and I have watched developers also express their feeling about this.

It seems to me that there are several ways of approaching this situation. We’ll certainly have plenty of opportunities to talk about the technical aspects of dealing with legacy code efficiently along the posts on Fluent C++, because legacy code is hard to understand and cruelly lacks expressiveness in general. But before this, it seems important to me to pause and reflect about what attitude and mindset is the most effective to have when facing legacy code, or otherwise non-expressive code for that matter.

The natural reaction: who the f*** wrote this

When navigating along legacy code we sometimes stumble upon things we don’t understand. A first natural – primal – reaction is to decide that:

• this code is a pile of crap,

• the person who wrote it had no idea what he was doing,

• we would have done such a better job,

• I’m way better than this, maybe I should find a place that deserves my skills.

Have you ever felt this way when staring at code you didn’t understand? I’ve seen many people do it. I’ve myself felt this primal instinct as well, but early in my career as a developer I took the conscious decision to act differently. Because even if I believe that this reaction is absolutely normal, that what’s it is: it is primal. Primal is good for surviving in the nature. But as a branch off the human race, we as software developers ought to quit this attitude and put on our rational hats. And being rational is what we are paid to do anyway.

Note that I’m not saying that the above feeling are always wrong. Maybe a particular piece of code is crap, written by someone who wasn’t qualified, and that you ought to be somewhere else.

What I want to do though, is show you another aspect of such a situation, that I hope will make you view it differently, rationally and hopefully positively most of the time. This certainly has helped me become more efficient and more content in my day-to-day coding in real codebases.

The rational approach: seeing legacy code for what it really is

I think it is important to recognize that legacy code is not the enemy. In fact in most cases, we’re here thanks to legacy code. The early stages of development of a given project was where it developed, captured clients, built up on cash and image to customers. This was done with some code, that is still around today, and that still performs the functonalities that your customers liked you for in the first place. This is legacy code. As its name states, this is your legacy. Without it you would probably not even get paid today.

Now let’s be super rational, and put ourselves in the shoes of the person that wrote that code.

Legacy code is often relatively (sometimes very) old. When you go back to the time it was written, do you think its author knew as much as we do today? Did he know the best practices that we slowly put together over the years as a development community, or the direction the language (C++11, 14, 17 for example) would take? When this code was written, did you know as much as you do today? Some pieces of code were written when some of us were still in college.

What’s even more humbling is actually thinking how we would have solved the problem that a piece of legacy code is trying to solve. When you glance over it, you can see things that seem absurd, and you are tempted to have this feeling of superiority by believing you would have done better if you had been given the chance. Maybe you would, but often when we actually try to solve the problem within all the technical or functional constraints that surround it, we realize that there are things that prevent us from doing a simple design, that we hadn’t seen at first sight. You really never know until you actually try it.

Still being rational, the image of this dumb guy that wrote this ridiculous code often doesn’t make sense. Legacy code becomes tangled and difficult to understand because of an accumulation of fixes, made by many people, that sometimes never knew each other. The first version of the code may have made some sense, but didn’t express its intention well. The following developer may have understood it a bit differently, adding a fix that wasn’t quite in line with what the code was designed for. When you add this up with many people over many years you get legacy code. This is one of the reasons why I think expressiveness is such a determining characteristic of success in code.

Anyway, the code that you see today and that made you – primally – want to hit someone with a club over their head doesn’t have one culprit. To be really fair, you would have to go see many people, some of them off to other projects, and gently tap their head with your club over which you’d have rolled some cushion. Or you can still bash somebody at random but there is no way that could be called fair.

Finally, let’s ask ourselves the dreadful following question: haven’t we written legacy or non-expressive code ourselves? When you look at code you’ve written a while ago, do you always perfectly understand it and even find it pretty? I certainly don’t. First of all, there is a context that we have when we’re “in the zone” when coding, that we lack when looking at code just out of the blue. And second of all, we get better. As one excellent C++ developer in my company once said: if you look at code you wrote 6 months ago and don’t find it could be improved, it means you haven’t learned anything in 6 months – and that is the worst you can get.

The efficient approach: taking responsibility

Now that I’ve hopefully made you see legacy code differently, what to do with it practically?

First, don’t complain if you don’t intend to improve the code. Complaining for the sake of it is just making noise. And this noise is detrimental for you and for your co-workers, because it creates a kind of negative vibration (or whatever you would call this) within yourself and in your office space. Moaning puts you in a position of victim, and not in a position of actor. And this attitude is contagious, particularly towards the youngest persons of the team.

So when you’ve got young developers around you, or if you are the manager of younger developers, you can choose to be a model for them in terms of attitude. It’s like watching your language around kids so that they don’t get a bad vocabulary. And if you’re reading this article towards the beginning of your career in development, please, choose the right attitude NOW.

What’s the right attitude then? I was lucky to learn it very early in my career from my fantastic manager Patrice Dalesme. A few weeks after I came in, Patrice gave us the following piece of advice: consider that the code you’re working on is your code. Even if you haven’t written it yourself, and however good or bad you think it is, this is your code and you have responsibility over it. For the record, I thank Patrice for this, even though I can’t say it’s the one thing I will retain as he taught me so many precious pieces of advice.

Anyway this piece of advice really shifted my view on the codeline. It was no longer something some distant people had written and that I could criticize to show how smart I was. It was my code and I was determined to make the most out of it. I came out of this meeting motivated to do whatever was in my power to understand it, improve it, and create business value out of it. Several years later I’m still just as motivated to do so.

Even if you can’t change the past and how code was written, you have the absolute power to control your attitude. Choosing the right one really makes a difference, be there in your efficiency as a developer or in your happiness as a person in day-to-day life.

Don't want to miss out ? Follow:   
Share this post!