What is legacy code?
Legacy code is the code you inherit when you take over a project, for example by taking over a team. It is probably poorly documented and tested.
The term could also be applied to your own code from three years ago. But when we call it legacy we are usually implying that it is the fault of someone else.
There are two ways to approach this situation: You can blame the previous developers, who left you with such a mess, or you can blame yourself, because you have so little influence on what the previous developers did. Either way it’s your problem now.
Is Legacy Code Good or Bad? The Decision That Only You Can Make
Legacy code is an unavoidable phenomenon in the world of software development. Even the best developers have to deal with existing codebases, and for newer developers, working with legacy code may be their first experience as a software professional.
You may have found yourself asking, “is legacy code good or bad?” The answer is that it depends on a variety of factors.
But what do we mean by “legacy code” anyway? For the purposes of this blog, we’ll define it as: any code that was written before you got there. This can encompass anything from a few weeks to several years, but it’s still all legacy code to you!
The term legacy code is used to describe a system or codebase that is old, complex, and difficult to work with. It may be poorly written or be written in a programming language for which support no longer exists.
It is often used to refer to the practice of trying to add new functionality without breaking existing functionality, leading to code that is complex, poorly documented, and difficult to maintain. Legacy code can also refer to software that is not actively maintained and has no remaining developer who understands how it works.
In general, the term “legacy code” has negative connotations in the software industry, but it doesn’t have to be so. It’s all in the eye of the beholder. While some would say that legacy code does more harm than good because it takes up time and resources during bug fixes and updates, others believe that legacy code can actually help a business grow.
We all have heard of the term “Legacy Code.” It is a term used by developers to describe code that ought to be thrown away and rewritten from scratch. But it almost always is not. Often times, this code is left alone because the cost of rewriting it is too high; sometimes, though a rewrite is justifiable, the company can’t take the risk of building new software that could fail.
Legacy code is troublesome for a variety of reasons:
It is difficult to add new features to legacy code without adding more problems in the process.
The older the legacy code, the more often it may be necessary to rewrite other parts of the program just so that it compiles at all.
Every time someone has to work with legacy code, they risk changing or introducing bugs in ways that can be difficult or impossible to anticipate.
Many of us have been in situations where we had to (or wanted to) write code that works with some legacy code, which is code that is not under active development but is still used by the organization. Maybe there was a library that was written a few years ago and has been working well so far. But now the requirements have changed and we need to add new features. Or maybe there’s an important part of the system that was written 10 years ago and has become a bottleneck and we want to replace it with something faster.
In these cases, we are faced with two choices: either rewrite the legacy code (aka rewrite it from scratch) or refactor it (aka make a series of small changes to improve its structure without changing its behavior).
The debate about whether it’s better to rewrite or refactor legacy code is as old as software itself. But from my experience, many people tend to underestimate the cost of rewriting and overestimate the benefits. In this article, I’ll discuss some common arguments for rewriting and refactoring, their pros and cons, and when you should consider each one.
Legacy Code is a fact of life. You can’t wish it away. It’s there, and it’s not going away. So you have to deal with it, and you have to deal with it as safely as possible. But how?
I’ve always thought that “Legacy Code” is a stupid term, because in the real world you don’t get to choose between Legacy Code and Non-Legacy Code. In the real world, all code is Legacy Code after two weeks.
So why do we treat Legacy Code as if it was a different kind of code? I think the answer is simple: because it scares us, and we want to pretend that scary things aren’t really there. Legacy Code is where the bugs are, and where all the work is, and where all the deadlines get missed, so we don’t want to look at it. We don’t want to be responsible for it. We don’t want to admit that our project has any Legacy Code at all!
And so we invent this term “Legacy”. It allows us to talk about something without actually talking about something real. We can talk about the fact that we don’t write tests for our old code (because tests are too hard), and feel better about ourselves
For the last several years, I have been working on a large C codebase. The codebase is over 2 million lines of C code and it dates back to the early 80s. When I first entered this project, there were a few things that struck me:
The code was in pretty good shape. It’s not perfect, but it’s certainly not bad. There are plenty of comments and some unit tests.
I have had little to no trouble understanding what the code does. This has made my job easier and more enjoyable.
The software has proven to be extremely reliable and very fast. The performance of this software makes it one of the best of its kind in the world (and I don’t say that lightly). Even though this software is old, it runs circles around other similar programs from other companies that were written recently.
This experience has made me think about legacy code and how people talk about it. A lot of people tend to think that if a piece of code is old and hasn’t been re-written then it must be bad. This may be true for some cases, but for many cases it’s not true at all! For example, if you look at Linux or FreeBSD or even Windows NT – all of them have been around for