You have hit the nail on the head – What you have complained about is the definition of “Legacy software”. Working on this class of software requires a different mindset to Green-fields work. Your stress is a result of you measuring your progress against unrealistic measures.

Don’t try to put todays ideology on yesterdays work. If it was not designed around TDD and UT, then retro-fitting Test driven methodology is a major, expensive and difficult undertaking. As you are finding – shoehorning todays silver bullets into yesterdays failed silver bullets is far from the ideal way to work. If carefully though through, with clear understanding of goals and benefits, it can be worth while. However, it quickly devolves into negative returns. Go for the “low hanging fruit” and develop tests only if it clear they will be used many times and find many defects.

The best approach is to remove unrealistic expectations. Productivity will be low, code hard to analyze and faults hard to fix. Unexpected side effects of changes are likely, and as you have found, regression testing non-existent- Maintaining Legacy code is slow and hard – thats why so many developers run off to Green Fields projects. I can be rewarding, but only if you reset your expectations.

When you start work on a defect, start by staying focused on three things – What the code does now, not introducing unexpected side effects and what it should do when fixed. You may find that “code duplication” is better than “unexpected side effects”….. Without decent tests and requirements, introducing regression is often the biggest sin of all.

Always strive to leave the code in a better state than you found it, but be careful not to change its behavior except where required.

This is always a frequent area of debate at user groups and conferences I attend. The best advice I’ve ever heard is this:

For new, well tested code, the tests are the source of all truth. For untested, legacy code, the codebase is the source of all truth. When adding a new feature, write solid unit tests. When addressing an existing module or fixing a defect, test as best you can, to avoid regression. Take your time, keep calm, and carry on.

That’s clearly a paraphrase of a few well-honed perspectives, but the core is this: the codebase is clearly ‘broken’, but the functionality isn’t and that’s what users care about. But if it becomes completely unmaintainable, and you have an idea about how to re-implement functionality quickly and sanely, it might be time to bring up the possibility of the dreaded ‘big rewrite’.

I admit that I’m in the camp that says the big rewrite is never a good idea, until it is. You, your team, and your customers will have to discuss and negotiate if or when that time has come. Best of luck, it’s a terrible situation with no one correct solution. I should know, I’ve been there before a few times.

This is slow work. Be patient. Your colleagues are probably the best source of information available. As you gain knowledge, add comments so the next guy won’t have to relearn what you already know.

This work is not a lot of fun, and doesn’t do much to advance a career, so you should be paid more than you would get for new development. I would probably not take on work of this type as a salaried employee. I would want to get contractor rates including overtime for the many “emergencies” that are sure to arise.

Learning how to read and understand other people’s code is a huge part of being a programmer. Some of the code you read will be your own. It can be dangerous to modify code when you don’t fully understand how it fits into the whole. Introducing unit tests and running them as part of some kind of automatic build system will help you keep the code they cover from changing behavior, but this means (especially with legacy code) that you have to understand how the code you’re changing is used by the system.

It can be tempting to throw away code that seems to be too complex (or crufty, whatever that means) and rewrite it yourself. (Everyone wants to be the architect). The danger in throwing away old code and rewriting it from scratch is that you’re also throwing away knowledge gained by time and hard experience that will usually be difficult to regain except by repeating the same mistakes and fixing the same bugs the original developers did over time.

Introducing TDD into (or on top of) a legacy system can be tricky. Be prepared to fix bugs in these tests as you will inevitably find inconsistencies in the code itself. Remember that your tests are not infallible. As you come to better understand the existing system, you will have to improve/fix them.

There is an approach that I found quite useful while working with situation similar to what you have described. Usually legacy code written in very monolithic and obscure way. But there’s an interesting approach to start working with legacy code: approval tests. I’ll recommend you to start with recording of golden copy and make sure that captured information contains values meaningful to your business. Next step, show that golden copy to business analyst. Usually, that are able not only to understand this representation, but also tell you what is wrong with those numbers, otherwise what are business analysts for? So now, you have both current result of program executing, commented by analyst, so you could safely start refactoring and bug fixing in your legacy code.