Staying out of (Technical) Debt

It’s a chilly Monday afternoon. I wave my ridesharing driver goodbye and find the nearest ATM to withdraw money in the local currency. I then find my way to what will be home for the week and pay for my stay. I’m getting hungry so I order my first Czech meal at a nearby restaurant, along with a compulsory Pilsner Urquell. On the way back, I buy pastries for the next morning. All of this is cheap by Canadian standards. Yet, those korunas are quickly fleeing my pocket. I feel like I should be careful. I rarely feel that way in my hometown, Montreal, where credit cards are accepted almost everywhere. Feedback on my spending habits is postponed until the end of the month (Did I really spend that much at Starbucks?).

Knowing about an habit just isn’t enough to change it. It helps to feel a little bit of pain every time. This principle applies, among other things, to code. Given a problem, there are as many working solutions as there are programmers, each with a different trade-off between implementation time and maintainability. Implementation time is easy to measure: it’s a number of hours. It’s an immediate cost. It’s what happens when you buy a Trdelnik with hard, cold crowns. Maintainability is harder to see. It represents how hard it will be to come back and make changes in the future. It’s like paying with the credit card. A quick solution that comes at the cost of maintainability is called technical debt: someone will have to pay for it at some point, often with compounding interest.

How can a team avoid crawling under technical debt? Make it visible. Experiment with code review practices where any important change is reviewed by a peer. Code reviews come in all shapes and sizes but one of their big benefits is that they make sure the code can at least be understood by another team member. Anything undecipherable will raise questions today and be addressed in a deliberate way rather than causing unpredictable problems along the way.

As I write this, I am sitting in a coworking space where coffee is included. At least, this puts a cap on my coffee spending. More generally, I have found that logging my expenses daily makes me more mindful of how I spend money, just like a good code review makes teams more mindful of the complexity they are introducing in an application’s code base.

Like this article?

Share on facebook
Share on Facebook
Share on twitter
Share on Twitter
Share on linkedin
Share on Linkdin
Share on pinterest
Share on Pinterest

Leave a comment