Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
possible duplicate of Becoming a "maintenance developer" –  gnat Jul 30 '13 at 5:02
Learning from other people's mistakes is the safest way to get experience... –  Michael Borgwardt Jul 30 '13 at 11:33
I studied other peoples code for about a month recently. Great learning experience, but sucked big time. Needed to experiment with sedating teas. –  usr Jul 30 '13 at 11:38
There can be good Java but it's harder to find for a jr. dev than devs of most other initial language backgrounds I would imagine based on experience which is primarily as a front end web developer gone generalist who's been exposed to a very wide variety of back ends. The problem I think, is that Java the language is perfectly serviceable but Java the culture is about playing absolutely everything as safe and blame-free as possible. –  Erik Reppen Jul 23 '14 at 3:40

5 Answers 5

up vote 24 down vote accepted

Troubleshooting exisiting 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 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 most legacy apps, the application doesn't have the 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.

share|improve this answer
Indeed, if you're going to have 4 months to study the code, you should spend lots of that 4 months adding comments that document what you learn, and writing tests that prove that key components work correctly (as one hopes they do). –  Ross Patterson Jul 29 '13 at 21:22
@RossPatterson, since this is banking, yeah I hope they really do work correctly now. At anyrate if there are no tests, then the risk of making a change is huge in banking and writing unit tests to help you learn the system should be an easy sell. –  HLGEM Jul 29 '13 at 21:25
Programming is knowing how to move the pieces. Understanding a system is knowing how to play the game. You will not regret the experience from the skill building standpoint. Working for companies that steal from widows and orphans is something your conscience may not tolerate. –  Meredith Poor Jul 30 '13 at 4:46

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.

share|improve this answer
It also helps you to understand taht the method you think they should have used was not available when the code was written. –  HLGEM Jul 29 '13 at 21:16
It would be great to find some code comments or project documentation in these situations. Otherwise that hack or weird way to implement a function will remain a mistery. That developer may not even be in the company anymore, so there's no way for you to ask him about it. –  Radu Murzea Aug 1 '13 at 8:28

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.