This week, I'm super excited to be getting the band back together! After several weeks of personal and professional obligations, Adam, Carol, Tim and I are all back at it again. And today, we're talking about Technical debt. When engineers talk about technical debt in public, they often try to use financial metaphors; such as taking out a loan (debt) in order to buy a house (value).
These financial metaphors romanticize the notion of technical debt, elevating it into the realm of calculated decision making. But, if I'm being honest with myself, is any kind of calculation really taking place when I create technical debt? Or, am I just trying to do the best that I can with the knowledge and experience that I have? In other words, isn't most of my technical debt really just the result of me writing janky code at the upper-limit of my capabilities?
All that and more on this week's show:
... featuring these beautiful, beautiful people:
- Adam Tuttle → Website, Twitter, LinkedIn
- Carol Weiler → Twitter, LinkedIn
- Tim Cunningham → Twitter, LinkedIn
- Ben Nadel (that's me) → Website, Twitter, LinkedIn
With audio editing and engineering by ZCross Media.
For the full show notes and links, visit the episode page. And, be sure to follow the show and come chat with us on Discord! Our website is workingcode.dev and we're @WorkingCodePod on Twitter and Instagram. New episodes drop weekly on Wednesday.
Teaser Transcript via Amazon's AWS Transcribe
This is me playing around with Amazon's Transcribe service. I always have to clean up the text a bit and add paragraph breaks after they transcribe it:
Note to Self: So many discussions about "tech debt" revolve around calculated decisions ie, the developer took a "shortcut". But, in my experience, most of my technical debt stems from incompetence, ie, naivete. Meaning, I literally didn't know any better at the time — there was no "decision" being made — love Ben.
Great job, great job. I love the way that comes out.
Alright, where do we go with this one guys?
I had this thought because, as I've mentioned before, I listened to a lot of tech podcasts. And, for whatever reason, it feels like technical debt has been a hot topic lately. In most of the discussions around tech debt, they try to come up with metaphors like: it's like taking a loan out to buy a house. So, you're taking on that debt, but it's for a good reason. And the underlying concept there is that you're making this calculated trade-off: I'm doing something that's maybe not the right idea in the short term, but it's gonna have pay off. And, I'm going to be able to pay that debt down eventually when I need to account for technical debt.
And I think it kind of romanticizes the idea of tech debt, making it into this thing that I opted into. And, as you may have heard me mention one or two times in the past, I work on a legacy system and that legacy system is littered with tech debt. And, as I've been maintaining it and I'm looking at all this code that I wrote years ago, none of it smacks of calculated decisions. It's all like, oh, I just didn't know how to write good code and that was literally the best code that I could write at the time and it's not romantic. It's not like I'm weighing pros and cons.
I don't know if that's a unique experience or if a lot of people are making real calculated decisions around tech debt. But I know that I'm not — almost the entirety of my tech debt is incidental shenanigans that I didn't know how to do anything about at the time.
So first off, I gotta say, I think you're putting entirely too much faith in people that take out loans, like financial loans.