The latest expert opinions, articles, and guides for the Java professional.

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!


Responses (14)

  1. Avatar  

    Jared Nagle

    February 20, 2014 @ 10:50 pm

    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!

  2. Avatar  

    Roberto Cortez

    February 21, 2014 @ 3:13 pm

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

  3. Avatar  


    February 24, 2014 @ 10:30 am

    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.

  4. Avatar  

    Dale Taylor

    February 24, 2014 @ 10:52 am

    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.

  5. Avatar  

    Vincent Fleetwood

    February 24, 2014 @ 3:03 pm

    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 :)

  6. Avatar  

    Oliver White

    February 25, 2014 @ 7:26 am


  7. Avatar  

    Oliver White

    February 25, 2014 @ 7:28 am

    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.

  8. Avatar  

    Roberto Cortez

    February 25, 2014 @ 5:15 pm

    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.

  9. Avatar  


    February 26, 2014 @ 11:43 pm

    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”.

  10. Avatar  

    Roberto Cortez

    February 27, 2014 @ 12:58 am

    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.

  11. Avatar  

    Hugo Araújo

    March 14, 2014 @ 7:47 pm

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

  12. Avatar  


    August 8, 2014 @ 1:37 am

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

  13. Avatar  


    September 18, 2014 @ 3:53 pm

    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.

  14. Avatar  

    Eric-Wubbo Lameijer

    March 5, 2016 @ 12:38 pm

    Hi Roberto, I like this post, and I definitely loved your talk on JavaOne 2014!

    Looking from a psychological point of view – have you ever looked at the Big Five model? Abbreviated OCEAN, it consists of Openness to experience, Conscientiousness, Extraversion, Agreeableness and Neuroticism. It struck me the Openness to Experience (especially the ideas/Need for Cognition/Typical Intellectual Engagement) may relate to the technology enthusiast, Neuroticism (sensitivity to negative emotions, like hating “imperfect” frameworks) with the Overenergetic Engineer (possibly with some conscientiousness mix-in), Agreeableness (wanting to help people) with the Firefighter, and possibly some Extraversion/Neuroticism combo (ambition overdrive) with the Smartass (though possibly some narcissim may also have been mixed in, or simply ignorance; in my experience, the less people know about programming/the longer ago they have worked on ‘real’ projects, the more they tend to underestimate how much work finding a bug or implementing a feature can be).

    That being said, you were perhaps a bit too polite: there are more than those five types. Some people are ‘eternal interns’ because they either don’t know or don’t care about programming (it was just the first job they could get). There is the “Burned out”, the “Learned helples”, the ‘it’s just a job”, as well as the “this is my first job, so this must be how the world works.” There is the “Coward” (“I don’t understand this code, better just add an if statement and hope it works since I don’t want to break anything and make People Angry (or Work Overtime)”), there is the ‘would be manager’ who wants to ‘produce quickly’ in order to impress his (or her) superiors in order to get elevated from the trenches to a position more suitable to their (self-perceived) managerial capabilities, the “Polyanna” who thinks that all possible styles of code are great or at least tolerable, and the ‘sea squirt’, who, like many a assistant professor achieving tenure has moved from the mobile stage in their career to the stationary stage and has long since started to eat his brain since he doesn’t need it anymore… Doubtlessly, any programmer who has been ‘in the business’ for any appreciable time can name quite some other types…

    That being said, I consider your types by themselves quite provocative, and inviting me to some self-reflection – like what type(s) I am, and whether I may need to start treating others like they want to be treated…

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.