Pros And Cons Of Working With Legacy Code

After my last blog post about legacy code, a colleague of mine asked me, if it is "good" for developer to work with legacy code. I found this question really interesting and inspiring, so I sat down and started thinking about it immediately. This post contains a list of pros and cons of working with legacy code. Enjoy, criticize, add your 3 cents, etc.


What I hate about it:

  • no new technologies (we all love shining new toys, don't we?), or older versions of the ones you know ("OMG, it doesn't even have X feature!")
    • loosing touch with the latest buzzing technologies
    • working with some forgotten technologies that you will never see again,
  • it is a minefield walk, and the feedback loop might be much longer than you are used to,
    • you have no clue what you can touch and what you can't - so you leave things as they are (even if you hate them), because there is no time to make sure that you can safely change them. This makes you feel really bad.
    • at the same time the project is on production (for ages) so it there is no place for mistakes,
  • very hard to write unit tests, and/or not much sense to write unit tests for bad-designed classes,
  • a lot things to do, but never enough time to clean it up properly (highly frustrating),
  • no one to ask about (you are all alone...), need to read documentation instead, if there exists any (usually incomplete and not updated),
  • the code is written in completely different manner than you are used to, it is hard to find anything, and even after long days working with it, you still do not feel comfortable,
  • PM: "it is such a tiny change, isn't it? shouldn't take more than two hours, right?" eh....
  • long time of searching, debugging, adding logs, writing tests, in order to fix some trivial bug or add a tiny new feature - something that in other well written project would take you 1/10 of time and effort. This means you feel like you have done nothing after a day or two of hard work.


What keeps me going (and enjoy it a lot):

  • there is so much to do!
    • it feels great to (successfully) introduce changes to the code, others are even afraid to touch!
    • making code better, so you know that you or other developers will have it easier next time (even if only by little),
  • mastering a debugger, maybe also a profiler,
  • master your automation skills - usually there is no 100% automated tests so it is up to you make them happen,
  • you will see
    • what damage a technical debt incurs, if it is not cleaned for months/years,
    • how bad design decisions affect the maintainability of the code,
  • a lot to do around continuous integration, code coverage, proper releasing etc. - the question is if you like to introduce such things
  • learn how others are (were) coding - you gain some experience by working with code written in very different style than you are used to.
  • learn how to write javadocs - you will meet plenty of useless javadocs along the way
  • become irreplaceable - "he knows how to fix X, we can not fire him" ;) - just kidding, if you do a good job, and automate stuff, and update docs, and write good tests, then you will not become irreplaceable,
    • but seriously, your knowledge of some older technology might be important for employees.

And The Winner Is...

My recommendation: do it, but only from time to time. Working with legacy code may teach you something, but the drawbacks are serious. 3 months is fine, half a year is still acceptable, but do not stay there longer - you will loose touch with the latest stuff and will have it hard to go back on track.

Hey, very nice analysis! It

Hey, very nice analysis! It is painful to work on legacy code, especially the owner has left your company. Though legacy code has many drawbacks, but we have to use... I think if you need to use a legacy code, you need tests. In particular, you need a good set of unit tests. The tests make it easier to detect changes that could be regressions. And the tests serve as the foundation that allows you to improve and simplify your code to make it easier to work with. How do you think? - calories in a banana | sinus infection symptoms | Brown Spotting

hen and egg

yeah, you need tests, but it is hard to write them, because the code is not easily testable, but you are afraid to touch it (to redesign/refactor so it is easier to test it), because you lack tests which would inform you if you broke anything... and so the circle closes :)

of course you can still do a lot - see


This used to be my blog. I moved to long time ago.


Please comment using