How to deal with an actively developed 20 year old legacy codebase

Question

I know there are potential duplicates, but imo this is different because there are around 100 developers actively working on this nightmare.

I have unfortunately gotten into a job where this GUI project exists. Development started around 20 years ago and it has to support different hardware and OSes (Windows, Linux).

There are 5 million LOC, with many files over 10k lines. This is absurd. All of Google Chrome runs on 6 million iirc. Needless to say the code is horrific. I have seen the same 20 lines copied hundred times with different numbers. Many defects can be traced back to bad coding standards such as single return in functions causing 20 indentation levels and old C standards where variables had to be declared at the start. There are way too many dependencies in each module, the interfaces are too large. Variable naming is terrible (with Hungarian notation as well), no principles such as SOLID are followed.

My manager says that the code simply is too big and old to change for the better, also many developers have an EE background and can't be bothered to learn modern practices. Is he right? Is the best solution no solution, instead just to keep slapping on requested features and bug fixes?

Answer 1

My manager says that the code simply is too big and old to change for the better

Managers don’t care about better code. Don’t ask them to give you credit for making it better. They wouldn’t know better if you dropped it on them. Managers just want reliable features fast. Give them that while making it better and they won’t care.

many developers … can't be bothered to learn modern practices.

Here’s your real problem. These 100s of developers should be able to read and extend your code. So if you want to introduce a fancy new practice/principle/tool you need to ensure they can handle it.

100 is far too many to deal with at first so find someone from the old guard and talk to them. Take them to lunch. Ask them how things work around here and if they’re happy with it. Learn what the real problems are. Maybe that brain of yours filled with fancy new practices can help. Talk it over and see if you can find support for the idea.

Introducing change is hard in the best of shops. In legacy shops it feels like it would take a miracle. But with someone who has mastered that nightmarish code base on your side you won’t just seem like some newbie full of book learning and no experience.

Answer 2

There is a difference between "Is there business sense in rewriting?" and "Will a rewrite get approved?".

It is likely that with ongoing development on a huge existing project, improving the code base would pay for itself in the long or even medium term. In general, a permanent increase in reliability and development speed just can't be beat.

However,

1. Managers often don't think long-term. They are evaluated at the most by the quarter, more likely by the month, and the very thought of not getting anything done for a month or a quarter in order to achieve better output in the next will horrify many managers to the point where they don't even think about approving a rewrite.

2. Managers often don't understand how the state of a code base affects development speed and reliability. They may think that you blaming slow development speed on previous bad decisions is a cop-out and that bugs in the code are attributable to bad developers not concentrating properly. This is all the more likely in that you can't realistically promise an increase of quality/speed in the future, just declare that you think it likely. A likely future improvement weighs almost nothing against a certain short-term loss in most management methods.

In other words, technical debt was a heroic attempt to make non-technical stakeholders understand that short-term results are a bad measure of ongoing development work, but in all too many departments it didn't do the trick, and you're stuck spending the rest of your career cursing, or changing jobs.

Answer 3

My manager says that the code simply is too big and old to change for the better, also many developers have an EE background and can't be bothered to learn modern practices. Is he right? Is the best solution no solution, instead just to keep slapping on requested features and bug fixes?

I have skimmed through: How to approach the BIG BALL OF MUD pattern from the architectural POV

There you will find good advice.

But one aspect is not mentioned -or I overlooked while skimming through- : Money - In your case €uros.

Even if you are well intentioned and have good strategies of how to transform the nightmare into a shining piece of diamond: Who is going to pay for this? and even more interesting Why should anybody want to invest money for this now?

If it worked for the last 20 years it will perhaps do so for some more years.

And when you tell us »My manager says that the code simply is too big and old to change for the better« there are no signs of pain your manager has or perhaps should have, meaning there is no economic reason to change the running system.

This may seem horrible for a young software engineer who loves good craftsmanship. But at the end of the day, you are payed to deliver running software and nobody cares about craftsmanship unless you could translate that into an economic perspective.

Without knowing the exact details I guess the calculation goes like this:

To make this thing pretty and shiny you need to invest the ammount of x €. After you went down this road you won to this point nothing. And more: The developers doing this job are hindered from doing productive stuff aka earn money with their work not costing something (opportunity costs).

Perhaps from that point in time - when everything shines - developers would be happy - which earns no buck. And changes to the code may also be cheaper. But is there a sure way to calculate how much €uros are really saved going down that road?

The other perspective is: How is the projected lifeline of the whole project? Is there an expectation to run another 20 years with this system? Or are there changes at the horizon of other machines coming needing another system?

There is the cost of running the system as long as possible and develop before EOL a new system (where you could help design a better system) vs weeding out the ugly parts.

And perhaps the former is better than the latter.

tl;dr

Is the best solution no solution, instead just to keep slapping on requested features and bug fixes?

Depends on how you define best: it could be economically more efficient to live with that Monstrosity and abandon it in the future completely for another system. But for that one has to crunch numbers.

At least you could make sure, new features are implement with craftsmanship in mind.