Does dealing with legacy code help one evolve as a programmer? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 5 years ago.

Improve this question

I'm a Java developer with a bit more than a year of experience which places me somewhere above a junior, but not among mid-level developers yet. Recently I was offered a long-term project which is about studying an existing banking application code for 4 months and then introducing changes when needed. As a not-so-experienced programmer I'm looking for ways to develop and I wonder what such a project might give.

Would you consider dealing with a big and probably not-so-well written application a good practice for a beginner?

Answer 1

Troubleshooting existing code is a super way to develop as a programmer. If the code is bad, you will learn the impact of the mistakes they made, and maybe avoid some of them when you are doing the designing. If the code is good, you will learn something about how to make a maintainable application.

You will also learn to deal with the complexity of a real business application. Since this is in the banking sector, you will learn about things like federal regulation and internal accounting controls that you may never have even thought of. These are good things to know when you get asked to design something else in the financial world. And financial programming can be quite a lucrative sector to work in, so getting banking experience may be very good for you.

You may even learn that just because something was written 15 years ago, in a language that you would prefer not to use, it is not necessarily bad. It has been running successfully all this time after all.

If, as with most legacy apps, the application doesn't have unit testing you need to really be sure a change won't affect something else, you may learn how to add that testing and how to sell management on why adding that testing is a good idea.

Answer 2

I think it's excellent practice for a beginner anyone. Learning from others experience can be very effective.

The real challenge is not to find mistakes, but to get into the head of the other developer and try to figure out why the code was written that way. Sometimes it's because they were sloppy, and sometimes it's because they had a darn good reason. Assume the dev was at least as good as you but may have had more domain knowledge.

Answer 3

This is good practice for any developer at any point in their career. If you can review and analyze existing software and find ways to improve it, you will demonstrate that you are a valuable developer. Not only will you learn how others have designed and developed software, but along the way you will learn what not to do, which is valuable knowledge in itself.

If you're up for the challenge, take this project head on and make it better.

Answer 4

It will absolutely help you, but you need to be careful.

You need to make sure you learn from the legacy code. How do you know what is good and what is bad? Maybe you can recognise the pros and cons of different patterns/methods, but if you were a junior developer just starting out, you may not be able to.

And stay too long in that first job, and you might not be learning or building enough skills and end up stuck there.

Answer 5

Legacy can mean anything but based on your 'not so well written' comment I'm going to assume that Legacy means 'bad' or at least 'out of date' technologies and patterns. If the legacy code is good, do not hold back and learn every line of it.

I don't think there are clear enough warnings against the kind of jobs and projects that divert your career and get you stuck in valueless sink holes on this thread to date.

Sports analogy alert: Do you think a line backer in the NFL learns more and becomes more valuable by playing on the team with the worst record or the best? My answer: Not only are they more valuable having played for the best teams, but they probably picked up best practices and knowledge and avoided picking up career ending practices and attitudes.

There is a lot of terrible anti pattern code out there that actually works for the business and pays a lot of dev salaries. I propose that a developer that hasn't seen enough code done the 'right' way might mistake anti pattern code for a legitimate solution to a problem. The business may say that the solution works, but it's not one you want on your resume or one that you would brag about to other developers. This is also only relevant if your personal growth path includes gaining the respect of your engineering peers and not just temporarily increasing the income of whatever company you work for (Sounds bad, but in the end, the best engineering absolutely makes the most money IMO).

Unfortunately there is a lot of code and a lot of time that can pass before tech debt is revealed. And that tech debt is usually recognized exactly when it is too late. Whomever may have tried to stop tech debt or anti patterns before, could have been sidelined because of the perceived extra expense or lack of understanding of scalability ect. It is our duty as engineers to expose tech debt right away. Projects without experienced engineers are in jeopardy of hitting a brick wall at some point, actually all projects even with talented devs. Most businesses view 'some point' as plenty of time to fix it later. This makes job choices for up and coming developers a very complicated matter. It also points out the entirely different goals and mindsets between developers and businesses and how complicated it is to bridge the gap.

It is the goal of engineers to 'include' real scientific work and design consideration while it is the goal of business to 'exclude' unnecessary cost and time. Since engineers often don't know what the level of effort and time is until the end state is actually done, software development plays out like any good drama with characters like agile, scrum, and kanban playing leading roles.

One take away might be to stay away from bad code until you have seen enough good code to not be 'corrupted'. I love the saying that senior developers create simple solutions to complex problems. Like wise, junior mid level developers create complex solutions for simple and complex problems.

Another take away could be that you need to work on good AND bad code at different points in order to gain understanding. If you have done neither then go for it and be prepared to unlearn it all when you come across a better system. I think this is probably a more common trajectory for most developers.

I'm biased this year because I'm feeling like I'm climbing an extremely complicated 'secret sauce' mountain. While I will increase my ability to decipher some of the worst patterns I have ever seen, it is so 'custom' and 'one off' that I don't believe my struggle will increase my marketability or my usable skill set in my future.

In order to keep my sanity, I'm just chugging along at a steady pace and embracing every road block as par for the course. Having just reviewed my yearly goals with my boss that include digging out of this legacy hole, I'm kind of thinking it might be a sacrificial climb. I could survive the process with bad reviews and perceived slowness. This is a realistic and foreboding warning to those of you wondering what job to take.

Disclaimer: This post will live much longer than my opinions so take it with a grain of salt. Tomorrow I might love legacy code! (Doubt it).

Answer 6

It very much depends on how you define "legacy" in this context. Let me give you an example from C and C++. Many C++ programmers call it a bad practice to use C strings in C++ applications, others demand no mixing, while others, in turn, claim that it be sheer and utterly pointless to use any bits of C code because they are old, i.e., "legacy" code. Some go further and avoid using pre-C++X (replace the 'X' with the appropriate number) standard idioms, style--that is syntax, for it's "legacy" style.

Leaving aside performance issues of C++ streams and strings and a few STL peculiarities, it sure is a great practice to have a look at what's inside your so much beloved preprocessor directive #include <string.h>. If you follow the path to the implementation and find yourself on a unix/linux machine at /usr/include/string.h (and get libc implementation sources, for example, from gnu.org) and read strcmp.c or strlen.c or strtok.c, I bet you're gonna hear "What a beautiful world" phasing in.

There is, however, a caveat to this prose--namely, deprecated classes and methods. In Java quite a lot of legacy stuff is still accessible from within a recent environment, but if I recall correctly, not everything. In the IB sector, from my own experience, well, not all software is written by good programmers. Lots of graduates had had virtually zero exposure to real-world programming before they started out at an analyst/developer position. But don't generalize this statement. I know lots of folks who employ Java and C# at the core of high-throughput, low-latency environments. I don't agree with them, but well, this is fortunately their business. Had they gone real HFT though, they'd get pushed way behind in the line. But again, easily inferred from this sentence is the assumption (and in many cases the fact) that Java code is highly optimizable. And if you can excel at optimizing, if required, not only fixing this or that, you'd become invaluable as a dev. It's very satisfying by the way to realize how much you have contributed. I'd go for it.