500 Words — Day Four: Technical Debt
One of the issues that I care strongly about is technical debt. At times, I feel lonely holding this position. Not many people quite understand how much this idea impacts technology today. They are focused on the potential upside rather the potential downside of the stuff we’re building. I’m here focusing on what appears to many to be a pessimistic viewpoint in such an optimistic field. As a computer science degree holder and builder of the future, how could I focus on technology and it’s potential problems? Or hold the more cynical viewpoint that technology is more about scaling one’s bank account rather than scaling human progress? But I have concerns and we can’t just ignore those, right?
Technical debt is a metaphor translating financial world to the engineering and technology world (often focusing on software, but applicable to other engineering disciplines). Just like any entrepreneur can take out a loan to accelerate building their business with a promise to pay it in the future, an engineer that chooses a deficient design that accelerates a product’s ability to be more quickly utilized or shipped to market with “the promise” to fix or refactor the design in the future. My problem with technical debt is that it is too often ignored and a lot of times not even recognized. Imagine thinking that you can endlessly take out loans and open credit cards and never paying those off. In software, a lot of developers are making bad decisions that compound on each other and yet are still totally surprised when bugs and defects kneecap a product’s development. You have to pay the bills eventually.
My preference is to avoid taking on technical debt in the first place. If you never take out a loan, you never need to pay it off. Good design is much easier to maintain and much easier to build upon. But let’s say you do have to compromise (which is often the case), awareness is key. And one has to be much more vigilant when it comes to taking on unnecessary technical debt. Because with money, it is a lot easier to conceptualize the negative consequences of not paying debt. You owe lots of money and that feels bad. With engineering, you spend long hours at night trying to fix something that just randomly broke ten minutes before the end of the workday. To many, that is just how engineering or software development is supposed to work. But that’s just an uneducated perspective, like the people that don’t understand credit cards. Engineering and programming are just more foreign languages than money. With good engineering and design, you take time to analyze your options, and adjust to new information and try to keep things simple. When your design becomes harder to understand or more confusing to explain, that’s a sign that technical debt is a threat and you might be taking out a technical loan that you’ll have to pay back or risk suffering under the weight of the design that you struggle to comprehend when everything is working.
They mistook leverage for genius. That sentence was used to describe how bankers repackaged garbage loans and doubled down on them using margin debt without understanding the risk they were taking. They were certain of uncertain things. Lots of engineers and programmers mistake complexity for genius. They repackage garbage design, hardware, and code, apply this repackaged junk to some novel problem and double down on it using marketing and promises of massive growth so they can obtain more money to repeat the process faster (we call that “scalability”). This is the massive acquisition of technical debt without understanding the risk that is being taken. What happens when a defect causes critical infrastructure to fail? What happens when it keeps happening? We are too certain about uncertain things. We are certain that our current technological trajectory will always lead to a brighter tomorrow. Maybe that is true, but I’m worried too many corners are being cut because they can be cut. Time will tell.
