Imagine a bacon-wrapped Ferrari. Still not better than our free technical reports.

The 5 people in your organization that grow legacy code


Have you ever looked at a random piece of code and wanted to rewrite it so badly you could taste it? Probably most of us! In the last few years, I have been working in several migration/maintenance projects and sometimes I just feel like shooting myself in the head! Ok, maybe that’s too harsh…

What exactly is legacy code? How can you define it? Is it old code? Is it code that no one wants to use? Or is it just badly-written code?

In my opinion, legacy code is software that developers usually don´t know much about, and they might even be too scared to change it because it can break something in the system. The tendency is to ignore it until the day it stops working and you need to start putting out fires…

This legacy code is just everywhere, man!

It’s natural to have legacy code in your application at some point, right? It’s something that you need to accept and learn to live with. Just think on how the market behaves. Most companies (usually non-tech) make huge investments in their software departments to solve their business problems and not to rewrite applications with the latest and greatest new frameworks all the time.

The speed in which the frameworks come and go is not really compatible with the life expectancy of the systems you’re developing. Take on look at the banking industry; there are a lot of banking systems being used in production developed in Cobol (and I know a few of them). Ok, let´s not go that far. Raise your hand if you know someone working with Struts 1. Have it up? Thought so.

So is this a lost cause? Should we just throw in the towel and give up? Hell no! Over the years, I learned to identify 5 main creators/enablers of legacy code on the engineering side, which I’m sharing here with you. Learn to keep them in line and your code will live longer!

The Overly Energetic Engineer


Do you need to kill a fly? No problemo! Use this cannon!

A few years ago, I wrote something similar to the current JPA Criteria API, not as good or evolved but I was very proud of it. Why did I do it? Because I could! And made everyone in my team use it. My colleagues nicknamed it CQL (Cortez Query Language).

Bugs? Only I know how to solve them. Status? Still used in a couple of very old projects with only maintenance operation, but mostly replaced and deprecated. Gain? Nothing. I had to teach everyone how to use it.

My point is, in-house libraries and frameworks are usually bad. Only a handful of people know how to use them and if they leave, you are going to be stuck with a piece of software very hard to maintain and to evolve. Try to use the most well-known standard frameworks. You usually have good support and a ton of people know how to work with them.

The Technology Enthusiast


Sound familiar? “OMG! I just had a look at the technology X and it’s great! We need to use it ASAP!”

A real technology enthusiast is always searching for the next awesome framework to use in your application. The problem is that you are already using 9012 different frameworks and libraries! Do you have room for one more? Can everyone in your team learn them all and deliver properly? Even if you cover those questions, the technology may not be mature enough for you to use.

I still remember when I first joined a GWT project. Don’t get me wrong, I think it’s a great technology, but I was “forced” to use it when it was on version 1.3 or something. Argh! The memories! No generics, slow compilation (ok, this still happens), no JavaScript debugger, no widgets and so on. I remember trying to find people to join my team and everyone looked to me with a puzzled face when I asked if they knew about GWT.

We actually got lucky since GWT evolved to a solid framework, but that’s not always the case. Bottom line: try to refrain yourself from including new libraries / frameworks in your project. You may end up with something that lacks support and it´s hard to maintain.

The New Intern


Hey, thanks for “Java for Dummies”, where should I inject my code?

Poor intern: just joined the company and already they are being asked to develop as a senior. Unfortunately it’s not the way it works. Developers need time to learn and produce higher-level quality code. Look at this example:

public static String getDayOfWeek(String data) {
        switch (getDOWNum(data)) {
            case 1:
                return "Monday";
            case 2:
                return "Tuesday";
            case 3:
                return "Wednesday";
            case 4:
                return "Thursday";
            case 5:
                return "Friday";
            case 6:
                return "Saturday";
            case 7:
                return "Sunday";
        return ("???");

It makes you laugh, right? Let’s think about this for a moment. Why was this code written this way? Most of the times I find out that the developer didn’t have proper mentoring and is unfamiliar with the current development ecosystem.

Invest in people, promote peer code reviews, do quick presentations about the technologies you are using in the project and teach others how to properly use them. Whatever works for you. Remember, there is no such thing as “my code” or “your code”, because if your colleague goes away it’s going to be your code! Helping your fellow developers to write better code is helping yourself.

The Elusive Firefighter


Remember Brent from The Phoenix Project? He was the man, fixing whatever needs fixing even in the most chaotic scenario. But at what cost?

A few years ago, I worked with an application that had hard-coded the max number of users that could access the application for licensing purposes. The number was low back then, since the company that was using it was also really small and nobody predicted that the company could grow beyond the limit. Guess what? That’s what happened!

The real problem was that the application just showed a blank screen and no warning about the real error. After a few days trying to understand the cause of the error (and a lot of pressure to solve it), the firefighter steps in and figures it all out. So they increased the value and redeployed. But then guess what happened a few months later? Yep, same thing again. Boy scout rule: If you see something wrong fix it properly!

The Smartass


OH: “That’s easy! I can do that in a couple of hours.”

Careful! This is by far the most dangerous profile. Often this developer doesn’t write code, but has plenty of advice for others about how to write it. Everything is easy to implement and can be done in less than 2 days.

What do you think that’s going to happen if this developer convinces your manager that a piece of software can be done in less time than your estimation? Even worse, they might actually be your own manager. So what do you do to fulfill the deadline? No javadocs, no comments, no unit testing or any testing at all! And that’s only the tip of the iceberg. We all know how code ends ups when it’s rushed right? Fight for what you believe you need to produce proper code!

Final words

Legacy code is going to happen to you, so it’s best to be prepared. It’s nothing to fear, but rather embrace. Just keep an eye on who actually contributes to and enables legacy code to really continue–we’ve got the overly energetic engineers, technology enthusiasts, n00b interns, elusive firefighters and good old smartasses too. Which type of engineer are you dealing with? Leave your comments below or Tweet me at @radcortez!

In case you didn’t see it yet, RebelLabs created a single page where you can find all our reports in one place! It’s called….the “RebelLabs All Reports” page! Ok, that’s not so clever when you say it out loud…

Take me there!