Today I want to talk about a topic that is present in a developer's life : legacy. This word means a lot of things in the IT world, and can be translated or interpreted in such many different ways. So here I will push my point of view as a developer, this is not a regular definition of legacy. The fact is, after experience, I don't understand why during all my studies, no one talked or teached about this, because it concern more than 50% of my career.

I want to talk about human legacy when nobody don't know how this feature works because "it was developed a long time ago by a guy who left the company". And of course about technical legacy : a language, technology, framework that is out of date or just dead, source code with no structuring or design strategy, no documentation, no tests. Legacy is everywhere, in each project or system, there is a part of legacy. You can't fight this, but you have to deal with it !

Don't judge too fast ....

Behind the scene maybe there are some people that in a particular context did this "strange" thing. When I was younger I pushed back these projects and judged first on the situation. "Why they did that like it ?" or "How the !/=-$ is possible ?!". But this was not the good way. Don't lose your time. When you think about that just look at a situation where you had to "do it fast", "do it now" or just "it has to works, we will QA later". Have a look at particular context of this situation, why you didn't do the best thing. There are reasons for that : insufficient time (deadlines ?), applicant never understood how a software works, your are new to the project, there is a lack of documentation, tools are out of date, you never worked with this language, or maybe you're just more experienced right now than the young developer who worked on the project (maybe it was a trainee or just junior) in the past ? Maybe it was not a developer at all ...

Nobody is perfect

We all do mistakes ! Yes even if you are a 100x engineer, you do mistakes. Because we become stronger and stronger learning during all our career. We start younger and become senior. There is a difference between a developer alone and a developer in a team. Sometimes a "POC" become a project but you didn't know at first, and you leave. The developer behind you will start with a "legacy" (don't tell me that all of your POCs are healthy ^^).

Analyse and secure

First of all : analyse situation. Which environments are available ? We got production, is there any staging environment ? Can we simply re-start project in local ? Is there any CI/CD process to put code in production ? Are there any tests that I can rely on ? Is code on git or svn plateform ? Do you get access to servers or tools or APIs ? Can we found logs somewhere ? Is there any backlog ?

And secure it as possible. Sometimes you won't get enough time to do all these shortcomings. You will have to choose and vote which one is needed. If project must go to live, GIT is the first thing we use to settle.

Tests just come next : how can we secure our refactoring without killing something ? Create tests, start as simple you can. A little but brillant guy always learned me : "1 test > 0 test". Sometimes you won't have suffisant skill to put tests in this from scratch project you don't know. Have you ever heard and tried Golden Master Testing ? This is so nice.

Read and learn

So when you get this project the first thing to do is something that you will do during all of your time : READ. Read code and LEARN. A developer will spend most of his time to read code, not to write code. One more thing that only experience has taught me : start small ! One small upgrade is better than no upgrade. Extract some parts away and test them. And repeat. So read, learn about the code, the context, you will find solutions and achieve to better things. Sometimes maybe, your search and work will conclude to a new project, or to kill a project. But this is at least, an upgrade of the project. Decide about kill or upgrade is not easy and it depends a lot on how much you want to invest on it, and which things we talked about during analyze (environments, CI/CD, tests, versioning, accesses, logs, backlog, etc.) we can push.

Legacy : the best coworker to learn

You have to practice a lot to deal with it, this is exactly the same as automated tests : you have use them every day at work, but it was a little part during all your studies (if you get lucky to get some courses on this). Sometimes you will compare yourself as an archaeologist or genealogist, and yes it can be exciting to interfere in a project that you do not know. At the end you will be proud of your work and you will have grown ! The fact is that this work of search, analyze, read, act is very formative and will bring you new visions for next projects.

I hope that these lines will help you to fight some deamons with legacy in the future.