Table of Contents
The moment working source code is live, it is legacy. The code is “in production” and has forever documented the decisions that created it. These decisions, big and small, are technical representations of customer requirements and market pressures. They also reflect the developer’s skills—an aspect seldom discussed when talking about technical debt.
A Tech Debt Background
Originally coined by Ward Cunningham, technical debt is a broad topic. Simply put, it is the series of tradeoffs that developers make when building software systems. The newbie creates technical debt when writing code to trade in crypto, and your rockstar 10x developer creates it when writing code that will launch satellites.
The malleability of software means it is easy to bend to the customer’s will, the pressures of management, the lack of tooling, or incomplete requirements. In other words, software’s ability to build anything means it is also susceptible to the pressures of time, money, and resources.
Time and money pressures on software development are easy to discuss, and so are resources when put in the same context. However, if developer talent is a resource, developer skill contributing to technical debt is rarely discussed.
For example, all things being equal, the newbie is probably incurring more debt than the 10x developer working on the same problem.
My Contribution to Tech Debt
I am a software engineer by training. What follows is a recreation of actual events. For the sake of preserving the anonymity of the participants, some details have been changed.
Scene: Circa 2014, at EZ Texting (then CallFire) offices on 2nd street, Santa Monica.
Engineer: I want to talk to you about AOP (Aspect Oriented Programming).
Me (with pride): you know I am a programmer by training, I wrote some of the first AOP code in the company.
Engineer: That’s why I want to talk to you about it. See if you really understand the concept.
Me to myself: That code helped us get to Series A to hire you to clean it up.
Punk.
Being Defensive
It is pointless to mount a defense about my code quality or parade my bona fides as a software engineer. It will only appear defensive. While I haven’t written production code since October 2012, I still write code today and sometimes get paid for it. However, unless for general comic relief, you won’t be finding my code published on Github anytime soon.
I am better at building a 50 person engineering team than being an engineer. And even that, I’d start by hiring the seed team of 5 who would help hire the other 45.
Some More Context
If I recall correctly, the AOP code was written around 2010 to help streamline logging. CallFire was growing rapidly. We have helped power the telephony needs of every major US Presidential campaign since 2008. So while we were good software engineers, the company’s growth pushed us to get better at real-time tracing of call and text patterns. I used AOP to create a framework that could log calls without making the code unreadable. It was my first foray into AOP, and I was learning on the job.
This engineer found himself doing what many engineers do every day: walking into a situation and cleaning up after someone else. In my case, the technical debt was, yes, attributable to new incomplete requirements, tight deadlines, and limited resources (writing code was only part of my job). But so was lack of skill.
Given that I had not been part of the engineering team for a few years, this engineer was also robbed of the tribal apprenticeship that any new engineer enjoys. The code had been in production so long that no one else knew how to use or change it. Apprenticeship, incidentally, is one way to fight technical debt, but that’s a discussion for another time.
The Reactive Response
My first response in sharing the interaction with the developer was to defend my skill. It is natural. All learned professions and the professionals who practice them have a high bar for entry and continued membership. If you practice it long and well enough, you become an expert. A professional becomes a craftsman, and with the pride of craftsmanship comes the natural impulse to defend it.
So the first step to addressing the role that skills play in tech debt is to stop being defensive about the work. There is no shame in work that represents your best efforts, as incomplete it may be, as long as it solves the problem at hand.
The Collaborative Response
A productive way to deal with tech debt caused by skill is to be upfront about it. Many technical practitioners become flat-footed when explaining tech debt to their non-technical colleagues. Some even have a perennial you-won’t-get-it response. This doesn’t help anybody and doesn’t solve the problem.
Being open to sharing and educating, you will find that your non-technical coworkers will be more empathetic to your challenges. Next time you ask for resources, be it additional QA engineers, developer tools, or cleaner requirements, you won’t have to explain why from scratch. Like in all aspects of life, transparency helps, especially when uncomfortable or inconvenient.
Finally
Technical debt is inevitable. Like entropy, it only increases the longer a system operates and the larger it becomes. However, you can stay ahead by addressing all contributing factors, including the developer’s skill.
I don’t recall what the engineer ended up doing with the code or what prompted his good-natured jab, but I do remember feeling rather good about a culture that allowed for such open interactions. And in some adjacent way, if only for a moment, I was part of an engineering crew.
Do you have a personal story about tech debt? Join the conversation on LinkedIn, Twitter, Instagram, or Substack.