Does this code sparks joy?
Hey!
Welcome back to another week of musings.
Back with more ideas around tech debt, how you had a restorative weekend!
Was this forwarded to you? You can subscribe here!
Things I discovered in the past week
- "What is a good question? And, how do we teach students to work at writing good questions?" Is such a great start to this post by Kyla Wazana Tompkins.
- I discovered this book vi Twitter/X: The Nature of Code. It looks interesting so I bought a copy but still need to read it.
Lately, I've been talking with multiple engineers about tech debt, every organization has its fair amount of tech debt they've accrued over the years.
During these conversations, one thing that came across was that some of the people wanted to remove code that they didn't understand, and this is the sort of thing that I wouldn't consider tech debt in some way. Sometimes the same engineer wrote the code they want to replace, other times there are newer ways to write it, or simply the team was re-org'ed(?) and there's no one left who understands what the code is doing.
I've also come across the other end of the conversation, where people automatically jump to write new services, or libraries to replace the old ones, without trying to dig deeper into the old code.
I've also talked with our Infra teams that provide core libraries so that the apps can run within our infrastructure, breaking changes because of product teams trying to unblock themselves to keep shipping. There's always this tension that the infra team needs to support a lot of old versions, and abandoned apps that might break if the wrong update is pushed to these libraries.
Am I So Out Of Touch?
Whenever I come across new codebases I need to research for either new features or places to improve for our new strategy going forward, I think about first if the code makes sense to me, sometimes it might not be "idiomatic" but it's getting the job done.
Other times, I might be "spelunking" the code base, because there's some tricky bug that needs to be fixed, in those cases, you already come with a preconceived idea that the code is "wrong". In practice, the debt comes from not updating the code to match current requirements.
Other times, we come across things like outdated runtimes (is your company still using Java8?), or libraries. In some cases, these are large efforts that take methodical steps to upgrade, like that random java8 service running in spring3 (which is the core of your business).
Remember that it's about perspective, the code might be good but needs to be updated to match current requirements, or the tooling landscape has changed, or simply the team has changed and doesn't consider these good enough under new standards. I recommend reading about the Mikado Method for refactoring.
Zero Debt is not possible
One thing I always keep in mind is that zero tech debt is impossible. Generally, I like the tech debt definition from apenwarr, and it's obligatory xkcd reference.
Tech debt, in its simplest form, is the time you didn't spend making tasks more efficient. --Tech debt metaphor maximalism (by apenwarr)
Under the idea that we don't spend all of our time just making things more efficient, we also invest our time shipping new features, library fixes, etc. We need to be more strategic about when and which debt we pay. The dimension we generally try to use is the risk, like how long before the end-of-life software we're using to deploy our software has a 0-day vulnerability and we need to remove it or upgrade to a newer version with so many breaking changes that we might as well remove it.
Build Trust with stakeholders
One thing I've seen happen is that we engineers are very worried about paying down tech debt. Often to the point that product or other areas wonder if we need to invest so much time in it. Whenever we talk about financial debt, there's good and bad, if we can keep producing more value than the interest we're paying then it's not that bad to keep the debt around.
I've seen some leaders remediate this by making tech debt "repayment" part of the same product roadmap, and building trust with Product that paying it won't delay new features, it will either give us more time in the future to deliver new features, or will generate savings that accrue over time.
It does require a leader who knows how to build trust, consistently deliver value, and make it visible to stakeholders what debt repayment is affording us to achieve each time we pay some of it down.
Your turn!
Let me know what you think about tech debt, and if you consider all "old" code to be debt, or is it wealth. Let me know by replying to this email!
Happy coding!
website | twitter | github | linkedin | mastodon | among others