8 Things You May Learn Working On Huge Legacy Codebase

During my career, I have worked both on multi-millions line of code project and brand-new project starting from scratch. What I can say is that you don't handle them the same way !

Here are 8 things I have learned from big projects:

1. It can take weeks to integrate a modification. Just forget about continuous integration, Accelerate, short iterations and that sort of thing. On multi-million lines of codebase with several hours of tests and very poor code coverage, you cannot apply classical "Red-Green-Refactor" TDD approach. You have to adapt, and be Agile 😉

2. Some behaviors are obviously buggy. There are even tests that validate this buggy behavior. And you must never EVER change the buggy behavior at the risk of making a lot of customer grumpy.

3. There is the Guy which is in the project since centuries. He has the knowledge. He has the skills. He has the vision. Without him, the project will go to ruin. And that Guy is underpaid.

4. It is in the end much safer to copy/past another line of if/else than trying to use the abstraction a contractor made 5 years ago for its own dedicated use case.

5. If you need to copy/past a code that can be factorized, either you rework all at once using a common abstraction, either you copy past again (the 1st one is off course the best solution). But do not create an abstraction for your own case and let legacy code as-is. Having several abstractions that do the same thing makes a global rework harder than having the same pattern repeated again and again. Homogeneity is better than specific genericity.

6. There are 2 kinds of behemoth projects: Those with good design and those with poor design. Those with good design have tons of features, and would end up with the same level of spaghetti code if rewritten from scratch. You will learn a lot on these projects.
   Those with poor design don't have a lot of feature and would require 10 or 100 times less code if well rewritten. Run away from these. You will just learn how to write bad code.

7. You will never know the whole project, you will always find something you never saw before. But there will be a point where, even if you discover new piece of code every day, you won't learn anything new. You will stay blocked in your comfort zone. Don't fall in this trap, or you will become The Guy we talked at point 3.

8. Be humble. You cannot rewrite the equivalent of several centuries of work in just 6 months.

And you ? What is the biggest codebase you worked on, and what did you learn ?