Hfrhyu

Legacy software is almost always a pain. There are many reasons why a re-write is not feasible.

What can be done?

1. Just maintain it. Implement the changes which are requested and only those changes. Try to do the best job possible, without overdoing it.




2. With agreement of your superiors (when needed), incrementally repair the mess. Be careful NOT to alter the behavior seen by the final user. If the behavior needs to change, go through a proper change request / bug fix loop. What you consider a minor bug fix can result in a major feature break for the customer.

I tell you this as I had to maintain 20+ years old software myself. I even had to branch "new" software from that mess. The only real alternative was to branch a big portion of a spaghetti code - against my wishes to rewrite everything.

The issue is so common and so widespread, that entire books were written on this. Just do a search on Google for books about dealing with legacy software.

I used to be in a company where I had to deal with two legacy applications. From what I understand, before they left, the two developpers managed to hide (or quick fix) the majority of the bugs when they appeared.
Fastfoward to one or two years after when these developpers left, the application were falling appart and users began to be frustrated. It took some time for my manager to really understand that the applications were not stable enough and like you said, fixing even small bugs began to take a long time for me and it began to really decrease my productivity when I had to create some new functionnalities.

So what I did was just being honest, every time I found something shady or breaking, I told my manager even if he didn't like it. At some point, he took the decision to hire people so that we could create new applications while maintening the old one for the time being.

In order to do that, I think you should document every bug you encounter, shaddy code and try to make them realize it's going to eventually cost them money and creatingmore and more trouble along the way. Don't count on your colleagues to help you with this. And if, at some point, you see no changes in your manager's opinion about it, I suggest you start looking for something else..

1) Become familiar with the goals of your company, the goals of your department, and the goals of your team. How do they all tie together? Discussions about technical debt should be relevant to these goals.

2) When you're discussing the problem of technical debt with non-developers, make it relevant by framing it as risk that the company needs to mitigate. Technical debt can make it harder to add more features, and can make releases more buggy, which increases development time, which costs the company money.

3) If you're not already doing so, start using source-control. You should be able to roll back changes if they're causing new problems. While you're at it, look into the other steps of the Joel Test.

4) Negotiate for time to address tech debt, and time-box yourself to that allocated time. As you investigate legacy code, you will find dragons. You won't have time to address them right away, but the wonderful thing about source control and branches is you can save your progress so that you may return to it later.

5) If you can't get your management to agree to allocate time to deal with technical debt, be sure to mention the impact the tech debt has on the development of new features they ask for, and its role in bugs that pop up. That will make it more visible.

6) Over time, if you still can't get buy-in to address tech debt, learn to live with it, or look for a new job if you can't.

This problem is often expressed in the software development world, because it's easily visible there. But the truth is, it generalizes to pretty much the entire business world. Whether it's software, or manufacturing, or service, there's always a process or function that can be improved. People in "engineering" roles (that is, roles that focus on designing and changing processes or tools, vs using them) often feel a sense of struggle because they can "see" the opportunity for improvement where those in more operationally-focused roles can sometimes seem blind to them.

This is especially true in software, because the view of the end product (the software) is very different - developers see the code, end users see the user interface.

Ultimately, there's a few things you can keep in mind:

Opportunity for improvement is always framed in a specific context. There are opportunities of a purely technical context (making code easier to maintain) and opportunities of a purely functional context (writing code that adds a specific feature). Ultimately, with software, there are often different decision makers for the different contexts - a business unit manager may be ultimately responsible for understanding and approving functional changes, while a technical manager, lead developer, or architect may be responsible for the technical changes. This split in responsibility can easily trip up a developer who's trying to get buy-in for a specific fix, because the business unit may be completely uninterested in a purely technical improvement, and they may even see such work as "wasting time" or even "risky" since it could potentially introduce functional changes or bugs.

As such, it's important to make sure you understand who the decision makers are with respect to bug fixes, approving timelines or levels of effort, and so on. As an entry level developer, it is sometimes the case that everything is filtered through a team lead or other person internal to your team, but based on your description, it sounds like you're getting caught in the crossfire between these decision makers.

Secondly, there will always be opportunity for improvement. Getting too focused on self-identifying and promoting those opportunities can be a slippery slope. Especially if "fix every last bug" isn't really in line with an organization's strategy for a specific piece of software. As you're finding out, sometimes when you self-discover a bug and work on fixing it, you can end up in what you're describing as a "can of worms." The lesson here is, while there may be things you see as bugs, it's important to respect the decision making process in terms of what you raise to your management and what you work on.

It can be easy to say, "hey boss, can I work on this bug I found?" when you're excited by the opportunity to fix something, but not yet truly sure of the scope or impact of the bug. As such, it's almost always better to take the approach of, "hey boss, we may have an opportunity to improve X. Do you want me to spend some time understand the scope and impact of this bug?" And if or when you get approval, it's important to tie it back to something concrete. "Hi boss, now that I've looked at the bug, it only really impacts X, and it will take Y to fix it." This way, you're removing the ambiguity of the situation, and you're helping those with responsibility for things like X (business or technical functionality) and Y (your time as a resource) to direct you effectively.

How Can This Chasm Be Solved?

Unfortunately you've set yourself up for a fall here by doing this;

As I had no other tasks, I tried to fix some bugs and in a subsequent discussions with the supervisor and the manager, we agreed that I fix one specific bug. This turned out to be a can of worms which I then attempted to fix. When 2 hours later I explained that I cannot give a guarantee to fix this within a week he started to get slightly angry, also pointing out he wants to present it on Friday and "the software used to work".

Short answer: Stick to the task at hand and don't broaden it unecesarilly.

Longer answer:Unfortunately because you tried to be productive you've uncovered more and more bugs and left the software in an unusable state. You've put yourself in this position on this occasion - You could have just truthfully said on investigation you have found that the issue you were supposed to work on is a non issue and closed the ticket.

The legacy software you're working on is messy for lots of reasons and some of the messy stuff is actually there to introduce last minute changes and bug fixes - In other words, wanted changes.

If you are required to work on and refactor this code in future then you first must make absolutely sure that you do not change the way it works. There are lots of good books and resources on the internet which will guide you in the art of introducing unit testing to legacy code.

There are a lot of good answers here, but I'll add another perspective, which is that the code and the organization (probably) isn't the problem here. Your desire to fix every problem may well be, along with what sound like some either tool or process issues.

First and foremost, you have to realize that you're working for a company now, and most likely, that company needs to make money. Therefore, at some level, every decision that is made should be one of cost versus reward. While the software may well have bugs in some sense, unless those bugs are somehow impacting the business, they're only theoretical bugs. It's entirely possible that people/other processes have come to rely on those bugs, for example. So before you go changing anything, you need to have a business case to make a change.

That business case may be that the bug is really impacting something else, and thus needs to be fixed. Or the business case needs to be that fixing bugs in general is so difficult in the code that by restructuring the code, you'll be saving time going forward. And if it's the latter case, that you're restructuring the code to make things easier going forward (ie, paying down technical debt), there's a lot of work you'll need to do before making those changes. Some of the books/links pointed to in other answers will cover this, but in general, you'll need to make sure that you have a very comprehensive regression suite, so that you can be sure that the change you are making doesn't impact anything else. If such a regression suite doesn't exist, you'd be much better served by building one before you go making any changes to the production program. Is that much less fun and satisfying than fixing bugs? Yes, but it means that in the future, when you do fix bugs, you'll be able to do so safely.

I'd also like to address your statement

When 2 hours later I explained that I cannot give a guarantee to fix
this within a week he started to get slightly angry, also pointing out
he wants to present it on Friday and "the software used to work".

There are a number of potential concerns here. First, does this mean that the program is now broken in production? That should never, ever happen for a voluntary code change. If it's some sort of emergency hot fix, it's not a great situation, but it's sort of understandable. But otherwise, from their point of view, you just violated the "if it ain't broken, don't fix it" rule. The code may be awful, it may perform badly, and so on. But it was performing an important service, and now it isn't. So, again, like the regression suite, your time would be much better served figuring out how to build a test environment where you can test changes prior to rolling out anything in production. And, second, this also suggests a lack of source code control, which, again, if you don't have, your time would be much better served building, prior to making any code changes.

Don't get me wrong, speaking as a pure computer programmer, it's really irritating to know that something I wrote isn't perfect. I look at code I wrote five years ago with some amount of horror, and I really want to go back and rewrite it. But as a software engineer, a large part of the job is making tradeoffs, and that code is still doing what it was designed to do, and rewriting it would mean that I wouldn't be working on new programs that are solving new problems. From a business point of view, it's much better for me to solve a new problem instead of solving an already solved problem in a slightly better way, in a way no one else will notice.