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

The 5 people in your organization that grow legacy code

1438.strip

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

roberto1

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

roberto2

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

roberto3

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

roberto4

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

roberto5

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!

 

  • Jared Nagle

    Okay, confession session, I think I’ve been a technology enthusiast and possibly a smartass at times. I’m notoriously making inaccurate time estimates and pushing the new frameworks onto my co-workers. Thanks for the wake up call!

  • Roberto Cortez

    Great you enjoyed it! As you may have noticed, I’m the Overly Energetic Engineer :P

  • mar77i

    nice article. Just writing this article to look busy, because the suit doesn’t care what the problems are or how I solved them. It’s simply work, and hell, I’m bored from the ever-broken php mess.

  • Dale Taylor

    Hey, man! That’s my day of the week code you stole without proper attribution. We were refactoring code from the French Revolution and we had to account for the possibility of 10 days in a week.

  • Vincent Fleetwood

    Maybe some developers go through each of these stages, starting with innocent intern. My favourite is the technology enthusiast – “I have a tool. Find me a problem and I’ll try using the tool on it. No problem too big or small.” Nice article – thanks :)

  • Oliver White

    Hahahahahahaha….

  • Oliver White

    Good call Vincent. These are probably impossible to exist as specific “labels” that you can attach to a dev, rather stages that can be accessed for each scenario according to how a dev feels at the time.

  • Roberto Cortez

    Hi Vincent. I’m glad that you enjoyed the article. Yeah I agree with you. Most likely people may identify more with one profile, but end up being all of them in different situations.

  • shogg

    So what’s the point of the getDayOfWeek example? You laugh at it but you don’t explain the mistake (much hubris?). It’s a minor inexperience. Strings in switch is not “higher-level quality code”.

  • Roberto Cortez

    Hi shogg, thank you for your comment. Maybe it was a fail from me for not making it clear, but is not about the code itself (that’s debatable), but it’s because you have multiple API’s that can give you the intended behaviour.

    It’s even easier now in JDK 8 with the new Date API, but you could write something like this for previous versions of the JDK:

    int day = 2;
    DateFormatSymbols dfs = DateFormatSymbols.getInstance(Locale.ENGLISH);
    System.out.println(dfs.getWeekdays()[day % 7 + 1]);

    And on top of that you can even get i18n.

  • Hugo Araújo

    Nailed it! I can relate to all of them during my career. Really great read, thanks man!

  • ElusiveAsWind

    Went through all the stage but settled at the elusive firefighter for job security.

  • T-100

    Excellent post.
    I propose an additional category: Sellers

    These people are external or internal to the company. These are dedicated to sell or buy mega tools: Oracle, IBM, etc.

    These will have no idea of how these tools are developed, the only thing they know is that brand is? and how much does it cost?

    Many tools are powerful, easy to use and flexible.

    But many others are terrible and impossible to maintain (IBM Products).

    Please think hard before buying a tool.