On Technical Debt

I read a lovely post on the React subreddit that discusses this issue and their suggestions for dealing with it:?https://lnkd.in/dmCVHvpi??

The answer most developers recommend to the person asking about this is: Run, Magdy, run! ??♂?

I wanted to share a bit of my own experience since I work in a legacy system and have encountered many issues related to technical debt.

---

First: What is technical debt, and why don’t most developers want to work on it???

Technical debt is basically:??

- Old code.??

- Written in inconsistent ways.??

- Lacks documentation to explain why it was written this way.??

- Nobody to refer to for help.??

- No unit tests, so if you make changes, you have no clue if you broke something else.??

In short, that’s technical debt. Do you think any sane person would walk into this bear’s den willingly? ????

This is why no developer enjoys working on debt, no matter how skilled they are. Some would even prefer to quit their job rather than deal with a legacy system because it’s a constant source of stress.

---

So, what’s the solution???

Should we just leave the module and component with 1,500 or 2,000 lines of code as-is, and every time we need a modification or a hot fix, we end up pulling our hair out???

Of course not. The root cause of technical debt is this exact behavior: developers are asked to copy-paste and tweak a bit of code, submit the work, and yay!—the manager is happy, the tech lead is happy, the client is happy, and other developer are happy… until we end up in the nightmare described above.

---

But what’s the solution then?

??

Here are the key points:??

1. Code Review??

??- Code review plays a huge role in preventing disasters like this from going into production!??

??- The team sees the functionality, but only the reviewer inspects the code itself.??

??- One of the most famous "last words" I’ve heard as a developer from a PM is: "We’ll revisit it next sprint!" And of course, we never did! ?? ????

??- Why accept doubling the effort and doing something twice instead of just doing it right the first time? Deadlines are understandable, but you can’t live your entire career chasing deadlines.??

2. Refactor Gradually??

??- Don’t dive in and attempt a big refactor, no matter how skilled you are.??

??- Use small tasks or requests on bad modules or components as opportunities to start improving them bit by bit.??

??- Read the code, try to understand it, and when you’re asked to do something similar, think:??

???- "Why not create a reusable component for this part?"??

???- "Why not write one function for both the old and new tasks since they do the same thing with slight differences?"??

??- By breaking the bad code into smaller parts, you reduce it gradually: 2,000 lines → 1,700 → 1,400, and so on.??

3. Unit Testing??

??- After dealing with legacy code and technical debt, I’ve realized that unit testing isn’t a luxury—it’s essential.??

??- When there’s no documentation, the test cases are the only way to understand how the code works.??

??- It also ensures that after a refactor, nothing is broken and everything still works as expected.??

Even now, I haven’t studied or written unit tests for my code, but after repeatedly struggling with unreadable code, I’ve realized that I need to start learning unit testing as soon as possible. It will greatly improve the quality of my work and make life easier for future developers.

---

And that’s a summary of my experience.??

#technical_debt #legacy_code