What effects does legacy code cause on a developer’s skills?

Question

Edsger Dijkstra once said that "the use of COBOL cripples the mind...". How about working on legacy software? Do you, as a developer, get crippled by that?

As an employed programmer, I have spent most of my time maintaining and fixing legacy systems. In my free time I constantly try to learn new techniques, languages or frameworks, but 8+ hours a day, 5 days a week I work on someone’s OLD crap application (I have, for example, worked with COBOL or EJB 1 or apps written in ASP).

I see a lot of questions on SO about technologies I have never heard of, and there is also a lot of people answering them. So, I am now wondering what effect working on old apps has on my skills.

A good thing that resulted from it is that I’ve picked up books like Code Complete or Refactoring, trying to ease my job, and I have learned a lot (i.e. even a bad example is a very useful example), but I am sure that there are also negative aspects of this (e.g. if I am out of a job, some years of COBOL don’t mean s**t if Web2.0 skills are demanded).

So, my question is: what do you gain and what do you lose, as a developer, when working mostly on legacy software?

Thank you.

Answer 1

I gain experience on refactoring, and I usually lose patience.

Answer 2

I think it is very effective at encouraging you to program on the side in some publicly visible way, either just by solving katas on a blog, but also by contributing to Open Source projects.

Answer 3

I guess it depends on what you want. I can guarantee there will always be legacy code out there to support and jobs available to support them. But if you want to be on the bleeding edge of technology, you won't be happy doing it for long.

Answer 4

Every time I work on legacy code, I die a little on the inside.

Answer 5

Working on legacy code can be very educational. An education on anti-patterns. You can see the full effects of code that disobeys solid design principles. It's a lot like those programs where juvenile delinquints would tour prisons to scare them straight.

Answer 6

I think there's a little prejudice at play here.

Just because code is 'legacy' doesn't necessarily imply that it's 'bad'. Yes, it's not going to be sexy stuff, and you're not going to get to do something cutting edge, but there's a lot of value in looking at old code and seeing how someone approached a problem.

I mean, come on. When you think about the luxuries developers have nowadays (craploads of disk space, memory, new languages/technologies), and then about how developers 20,30, 40(!) years ago were creating code of lasting value, it shouldn't make you automatically discount code from that era as "crap", but rather it should make you say "hmmm, they got a lot done with a lot less than I have to work with, maybe I should approach this with an open mind".

That said, there is crap out there, and if you run into it, well, it's a good excuse to read Michael Feathers' excellent "Working with Legacy Code".

Answer 7

For me it really is educational.

Where I work it isn't the fact that the languages are old that were used but instead the design patterns/technology that went into the program. We have for example programs that were programmed as MS Access programs that support parts of our corporate enivronment. We also have many apps that are still running new technologies (in context) such as .Net 1.1. Even though the technology isn't that old it is easy to see the old ways of thinking.

So what we as a team try to do here at work is identify areas for improvment within this older code base and react to the pitfalls of the past in our new projects.

The other thing I have personally learned from working on older code base is NEVER jump on the band wagon of new technologies right at the start. We have stuff that should never have made it into code that some hotshot developer we hired decided was the next best thing.. We all pay for it now! :P

Happy holidays, Mike

Answer 8

Hi

If you work in IT for more than about 3 years (that is, longer than the lifespan of most software technologies) you are going to work with legacy code. For heck's sake I've seen books which refer to Java as legacy code -- to a Fortran programmer like me that's rich. I think the ability to work with legacy code (whatever your precise definition) is one of the most useful and durable skills to have in your toolbox. It's a lot more valuable than knowledge of ephemera such as .

Regards

Mark

Answer 9

IME, I've gained looking at various patterns in use and how some things were done where I worked. There is also something to be said for testing one's abilities to quickly read and understand the code so that fixing a bug doesn't take weeks if the only code change takes all of 5 minutes or less.

While I may lose on not using the latest and greatest, sometimes that isn't a bad thing. However, legacy merely means I inherited it and it may have been written by something fairly new, just the person that did write it left and so I got stuck with it, for example.

Answer 10

You lose experience building systems with newer tools; for example, I work on legacy systems, and I don't have any AJAX experience, which would arguably be nice to have.

Djikstra said "Computer Science is no more about computers than astronomy is about telescopes." You and I work on telescopes; we ship code. He worked on theory; he's the astronomer. As a specialist in theory, languages with GOTO statements might ruin you. As a mechanic - my job - I need to be able to read all code, good and bad.

Answer 11

Along the same lines as compulsiontocode:

Not learning from your own mistakes is human. Not learning from the mistakes of others is just plain stupid.

I gain personal satisfaction when I succeed at undoing some heinous (or just some naive) code. There is value in the legacy code and it is usually the application bringing in all the money. I do strive to learn from the mistakes I undo and it does reinforce the need to stick to sound principles. So it does not get me down to work on legacy code. The only time I'm pissed is when I can't refactor towards goodness (release pressures or bad managers).

And I'm not under any illusions of greatness. The stuff I wrote yesterday is legacy code even if I did write unit tests.

Answer 12

Let's define some terms first.

Legacy is not necessarily bad. It just means "installed and running". That said, it can also mean old. And lots of old code, written before the modern day, where code is beautiful and written completely bug free through magic IDEs and testing methodologies, tends to lack the foundational structure that makes evolution more accessible. In other words: legacy code isn't always bad, but it usually is.

As others have stated, the ability to work on established systems means you'll always have work. But in terms of skills here are some general observations from someone who has to work on it a lot, from the perspective of a developer that works for a non-software company:

• Refactoring skills. compulsiontocode said it in an earlier post referring to anti-patterns. You will get tested trying to get some nasty code to behave, and for your sanity you will probably learn a lot about reworking code just to be legible and less confusing (improving variable names, de-cluttering deeply nested loops and IF statements, and implementing improved exception handling). You can learn this even working on new code that is not in production, but it tends to be less of a focus. In fact, depending on how the project is managed, the focus is probably on "getting it done yesterday" which means the programmer on the new stuff is doing the slaphappy cowboy thing and is creating future work for the legacy maintenance guy.
• Detective skills. Legacy Systems are notorious for being poorly documented. It will take careful investigation to identify defect sources, and time must also be spent researching hidden dependencies because testing is likely manual.
• Bureaucracy Tolerance skill. For corporate systems of import or that deal with accounting, maintenance developers may have to deal with regulatory controls such as Sarbanes Oxley. This is a synthetic hurdle that greenfield developers largely don't have to deal with until deployment time. But maintainers of legacy code are regularly rolling in fixes and adjustments to a production code base, and even simple changes require forms, signatures, justifications, proof of business authorization, proof of testing, and proof of managerial review, mostly from developers that don't like documentation, users that like documentation even less and have no time to test the things they are requesting, and managers that don't really understand the low-level things they're being asked to sign off.
• Risk Management skill. Once a system is in production, the emphasis is no longer on enabling a new system but on preserving the working parts. Changes made now must be based on the existing foundation. There may not be time or focus enough on allowing substantial refactorings that are not business-justifiable, even if the technical debt is high. Changes, unless approved as a project, tend to be incremental and requests to engage in innovation are harder to approve. Even things like deployments are done with some measure of risk aversion (dangers of month-end, year-end, etc).
• Creativity in Problem Solving. This is a skill important to both greenfield and maintenance developers, but there are some interesting differences. The greenfield developer starts with fewer limitations. The maintainer of legacy code has to accept the existing strengths and weaknesses of the current foundation and also take into account the factors mentioned in above points.

As to your point about not knowing newer technologies, definitions are again important. Technologies are not the same as skills. If you understand object orientation, or patterns, or particular logic constructs, or databases, those skills are transferable to new technologies. Many on StackOverflow have noted before that good programmers can always learn a new technology, but the core skills can still apply. I think what happens as a legacy guy though, is that you can get into a situation where your skills don't evolve as new technologies find newer and sometimes very useful ways to apply them. In PowerBuilder, I have done inclusional polymorphism, for example, but Java and .Net also have operational polymorphism.