Back to the future — Legacy code
Today someone raised a question in one of the Facebook groups: ‘Is legacy code inevitably crap?’. Unlike my earlier posts we won’t start by creating some legacy code, so if someone came in hope of some copy-paste material: I have bad news for you :) But if someone were interested in an opinion about legacy code he can find it :)
First of all let’s see the definition: what counts as legacy code? The word ‘legacy’ isn’t the synonym for ‘crap’, nor for ‘endless pain’ and there isn’t any evidence that it must be COBOL or FORTRAN either.
If we ask wikipedia about this it will tell us a bit more about the topic. It states that a codebase becomes legacy if it is related to non-supported technologies, e.g. we must support serial port, windows XP, IE7 or PHP 5.2.4. So Wikipedia generally says that backward compatibility is the main issue mostly if we maintain code for waaaaaaaay too long. If we think about Wordpress, we already got the first case where they can’t clean up because it still compatible with PHP 5.2.4!
Most of the time we don’t have to travel back several years in time to find such monsters. There are several ways to work as a programmer. If we highlight PHP then we could be employed by a multinational company or a smaller one or we could do it as a freelancer. Working at a big company doesn’t means that people actually work together as there are several companies where they just churning out microsites. Most of the employers are hiring ‘full-stack gurus’ nowadays and the developers there can be assigned to a single project which they could finish without ever speaking to others than the designer. This also applies to freelancers and smaller companies. And when someone works alone for a longer period of time they get lazy. No one looks at their code, no one blames them, and there are no standards to comply to. But there is one thing:
the deadline.
If there aren’t any quality expectations then there will be quantity expectations and those will come from the management side.
Let’s look at the story of Dave:
Our full stack developer friend just got hired to a small company where they mostly pour out micro sites. They aren’t doing agile but instead worship something called ASAP Driven Development which basically means that everything should be done the day before. Dave is a developer with principles so he tries to organize his code well, using translation keys in the view files, etc.. by and large he does a great job. With this attitude he could ship smaller sites in a reasonable pace. But the project manager has a motto which states “you should drop more and more tasks on the developer because as long as he can carry it he has more capacity” thus he find our Dave’s work slow and expects him to do better.
On one of those status meetings Dave accidentally mentions “if I hurry even more the code would be ugly”. The PM needs no more confirmation so he rebukes poor Dave as he’s wasting his time on non-business related factors is slower than the others. As software developers are not known for their assertive behaviour, Dave couldn’t stand up for himself so he falls in line with the other coders. From now on he refuses to write unit tests, ignores SOLID principles, mindlessly copies classes from the previous projects, hacks into composer packages because there is no time for the pull requests and so on. The project manager is glad as he noticed that Dave’s performance was twenty percent better than ever.
As the months pass, Dave attempts to be even more productive. He queries the database in the view files, drops frameworks and carries a functions.dave.php file which gain weight from project to project. As he became the most productive developer, management decides to promote him. He becomes a senior developer. The new title comes with new responsibilities, so from now on he has to ramp up newcomers as well. He makes them sit down at his computer, opens one of his past projects in the IDE and shows them the functions in his mighty functions.dave.php The poor guys learn the meaning of legacy code here.
But Dave wants a change in environment so he moves toward another company. This firm isn’t specialized on small sites but bigger, more complex web applications, where a product and their components are developed for years. A colleague described the ticket workflow to Dave:
- You develop the code. The code that has no tests against it is as if there were no code.
- If you are done with this then you ask a QA to help you out and together you investigate the issue, to see if you covered every necessary flow.
- Then you make a pull requests and ask us to review it. You also have to review others’ code!
- When you fixed the review items or discussed them and they approved your pull request THEN and ONLY THEN you should merge it to the master branch.
- You should spend 15% of your time on tech debts each sprint if possible.
This shocked Dave as it was a completely different approach than the one they followed in their previous job. The codebase was huge, hundreds of classes piled up, but every public interface or class was nicely documented and there were no two differently formatted files. During the reviews he saw many new techniques while investigating other one devs’ code. They also held a weekly coding dojo where they could’ve learned every aspect of the IDE and the core API.
Get Krisztián Papp’s stories in your inbox
Join Medium for free to get updates from this writer.
The promotion were not based on the amount of resolved tickets, quantity does not make up for quality here as the team must maintain the codebase and as the tech dept list grows it will hurt more. The managers were aware of that fact. This was a different kind of legacy code which is not bad, just old, but due to the continous refactoring there were no part of it which hasn’t been revamped a bit.
But let’s see another example.
We have a codebase, which had been written in prehistoric PHP more or less 10 years ago. It was the time when PHP 5.2 got the JSON extension, but the hosting providers back then were like they are now, applying new versions pretty slowly.
Then we met this code and we could hardly hold back our tears because we see a function which builds up a JSON string ‘by hand’. What the ???
Then we check the docblock at the top of the file:
Date: 2006.02.11After some quick calculations around PHP releases and we find that only the latest 5.2 version had json_encode/decode (Don’t forget PHP 4 was a thing then!). Then we think about that there are many hosting providers around which still runs PHP 5.5 so the whole code makes sense now.
But if that codebase were made last year we would question that person’s PHP knowledge. The developers of PHP are working hard to extend the available toolset and hence make our work more efficient so don’t be surprised if there was no Java 8 calls 10 years before or JSON encode while using .NET 2.0.
The PHP is a quite special case as the ratio of freelancers are higher and they tend to work alone. As I have mentioned before, if someone works alone then they tend to be lazy, negligent as there is no force making them comply to standards, principles.
What could we do to avoid leaving monsters like this behind?
- If your company doesn’t respect code quality then leave it or take refactoring into account while making estimations and don’t let others influence you in this. Principles!
- Work together. If you ended up at the same place, learn from each other. Other people may know some fancy keyboard shortcuts or API call which you have no idea about.
- If you aren’t able to work together during office hours then attend Coding Dojos or organize one in the office.
- Open-source! If you are working alone then hop on a github project and you’ll be able to cooperate and learn from others.
The moral of the story: A codebase don’t have to be old in order to make you cry.
