We’ve all complained about technical debt and legacy code, but it’s not all bad.
When I was a junior dev, I would complain about lots of existing legacy code that I encountered. I ran into a lot of it doing contract consulting work. This wasn’t just the obviously bad stuff, either, like finding some homegrown ORM using non-parameterized SQL queries being read from XML files. 😬
I complained about the little things. Like using a loop or if statement that wasn’t the most optimal, or copied code, or someone not using some library I thought they should be using. Honestly, I still fight that temptation sometimes. It took a few projects to really get perspective on technical debt, where it comes from, and how to appreciate it.
Often, technical debt sold the software to allow you to have a job.
Think of the times you had to add technical debt. It was likely to hit a deadline or meet some pressing customer need. Those pressing sprints were typically when a high-paying, critical customer needed something. The key to effectively working with technical debt is don’t become over-leveraged.
Strategic technical debt can bring you key wins at times that you can pay back later, but if you become over-leveraged with technical debt, and don’t pay it down, you eventually come to a point where you’re unable to move forward at any reasonable pace.
Sometimes code isn’t optimal but increased MRR (Monthly Recurring Revenue) just enough to allow for hiring a new person – you.