Who ordered the scrambled brains?

No, I’m not referring to some French culinary legislation regulating the feel of that peanut confection, but rather to a property of—what else—software.

The idea of technical debt is critical to employee work-life balance and to customer relationships. However, many companies these days seem willing to carry that debt, obsessed with a “move fast/break things” culture where any efforts resembling code perfection are feverishly rejected. But technical debt is a strategic concern, so one would think all those business strategists in their fancy suits would find want to address it. Without adequate recognition, the emphasis inadvertently shifts from “moving fast” to “breaking things”. I believe this lack of due attention is largely a matter of poor communication by engineers with stakeholders. Technical debt is often misrepresented as a temporary issue. “Give us a week to erase this technical debt.” On the other hand, saying “Each work item carries with it a 15% implementation tax to mitigate technical debt” is no more reassuring.

The term “technical debt” is an attempt to use business-friendly language to describe a less tangible quality of software: its capacity to be changed. Code that took a lot of shortcuts will be harder to change in the future, so it’s said to have technical debt. Removing the shortcuts and doing things more “cleanly” (if also slightly more “perfectly”) makes the code easier to change in the future and therefore reduces its technical debt. However, while it nicely sums up the idea that work will slow down (the “interest” that must be paid when changing a piece of software that has technical debt), it misrepresents the cost as a static sum that has already accrued. In reality, the cost of difficult-to-change code is proportional to the changes desired in the future. So you can only really assess the technical debt in the context of proposed changes. In fact, technical debt has no cost if no changes will ever be made. The problem is, one can never be certain that changes won’t be needed. Especially in today’s rapidly-evolving media and technology landscape, it’s far better to assume changes will be needed.

So it’s important for the language used to capture the business vulnerability that is associated with difficult-to-change software. While we could adopt a serious-sounding color-coded threat level system, I prefer a less theatrical, more tangible metaphor. I think of software change capacity as “software malleability” or “software brittleness”. The more brittle some software is, the more difficult it is to change it. Therefore, changing brittle software requires relatively more time. Unfortunately, the Law of Brittleness (I just made that up) states that, barring specific effort, changes to software tend to increase its brittleness. Only consistent focused effort can manage brittleness and keep software in a malleable state. This explains why brittleness increases particularly when changes are made in restrictive time constraints. Critically, as changes are made without adequate time, brittleness can compound such that the time cost of future changes increases exponentially.

That is a dangerous, unsustainable place to be in. It means the business is less able to respond to changing demands, threatening their value, customer relationships and brand. And it means that more and more pressure is directed onto engineering teams, who cannot fight the Law of Brittleness and therefore can only alleviate the pressure by eschewing work-life balance. Saying “we have a lot of technical debt” doesn’t convey “we are dead in the water unless the engineers work overtime.”

Then who gets the final say in whether software is brittle or not? The engineers do, since they are the ones who know the software internals and will pay the price later on. They should be trusted to assess the brittleness of software, and therefore they should be allowed to mitigate it regularly. Anything else is unsustainable. “Won’t they just abuse the privilege and underestimate work just so they can sip cocktails on the beach?” Unlikely. And if stakeholders are unhappy with this structure in any way, they always reserve the means to address it (replace the engineering team, hire more engineers, outsource, or accept the unsustainability and adopt a “burn-and-churn” human resourcing strategy).

This also means that engineering teams are charged with assessing brittleness and raising brittleness as a concern. Since it’s so intangible, assessing it can be hard. Something that gets the team pretty close is to rank the codebase (or parts of a codebase) on a brittleness scale form 1 to 5. What this assessment really translates to is a gut feel of how comfortable they’d be making changes to that system. Ideally, engineers would feel no hesitation or discomfort to the notion of changing some module. But for time-impacted projects, there will invariably be areas that the team hopes will never need changing, and may exhibit violent involuntary spasms at the thought, due to the disastrous brittleness of the code. Assessing and raising these concerns doesn’t just benefit the business. It protects their own work-life balance, which keeps their average hourly compensation from reducing to peanuts (brittle or not).

Follow me on Twitter for the latest updates, and make sure to check out my community opinion social networking project, Blocvox.