Thinking About Legacy Systems

Every software that you write which goes to production, will either become a legacy system because people will use it, or it will not be successful.

If anything, this should make you think about how you write software: every successful software becomes legacy software. Every single one of them. A successful software might be re-written: the windows operating system, the angular project, etc. This is, however, not often and not the norm (and expensive.) In most cases (and I mean in almost all cases), a successful software lives very long, and sometimes outlives the expectations the authors had for it. Successful software lives long because people use it, and it is under constant change because users demand it, and it only gets better because users want it. For better or for worse, this is a fact of life that software engineers have to live with.

A legacy software is any software that lived “long enough”, for some short definition of “long enough”. Or it is a software in which some changes causes a pain for developers. Some define legacy software as software without tests. Some define it as software that is done.

I will use legacy to mean a system that is unmaintainable that no one wants to touch. But whatever a legacy software is, you will be working with one, if you have not already. Here are my advice for you.

Learn Software Design

Software is legacy because of two reasons: (1) it is built without reasonable design from the ground up, or (2) it was maintainable at one point, but developers neglected or changed it without a reasonable design.

Preventing (1) requires knowledge and experience in software design and architecture. Not only that, but it also requires that you and your team of developers are all on the same page when designing. Inexperience developers might not know design or might not think of it as important. Hence you need to make sure they know it and its importance. On the other hand, other senior developers might disagree on design because of their different experiences. Hence you need to ensure the whole team is on the same page.

How to achieve that? Unfortunately there is no clear path to achieving that. Disagreements will always arise regardless. But here are some method that you might find helpful, since they worked in my case:

• Encourage your team to read books and discuss its content. Books are still one of the best resources to know the theory of software design.
• Present on design, and bring examples from open source projects if you know some. This is to show that these practices are being used in the wild.
• Discuss design before implementing it. Discuss the classes you are going to create, the interfaces that you are going to add, and the changes that you are going to make in the source code before implementing. This is to get the approval of everyone, and to make sure that the whole team is on the same page before implementing. A small discussion upfront saves a long time with code review later.

Snowball effect

In most cases you will find yourself with a software that has already been built (by you or by someone else). There is one and only one way for any software to become unmaintainable: by creating very trivial unmaintainable pieces one at a time. There is no other way. A person adds a small feature, and does so without any regard to the design. Everyone approves the change because no one want to understand the design, and because no one sees any harm with a small hack or strange code. Repeat these steps, and you will find yourself in a horrible legacy software you no longer want to touch.

This is case (2). There is only one way, and it is the obvious way, to maintain already-built software: by preventing these small unmaintainable changes from ever going into the software. Easier said than done, but this is the only way.

Be looking for improvement, more helpful tests, better design, etc. But be also very particular about the new code that comes in. There is no other advice that will do beside this: prevent people from adding unmaintainable changes to the codebase, regardless of how small they are.