Learning to Swim in Tech Debt Part 1

Tech Debt has a habit of drowning the unweary and unsuspecting software engineer. For a few years now I’ve been drawing this graph on the back of napkins for software engineering managers of struggling teams. It is the tell-tale sign of an ailing software organization which has become a victim of its own success. Unbeknownst to the undiscerning observer, the team’s star profit making deliverable can no longer sustain rate of innovation to remain competitively relevant.

The graph depicts the cumulative delivery timeline for a software development team. Readily apparent is the initial high rate of delivery and the subsequent gradual but steady descent of this rate. This is surprisingly the most common pattern, and if caught early is a telling red flag indicative of an asymptotic ceiling leading to a chronically unproductive team missing any and all delivery timelines.

There are a few reasons for this dysfunctional pattern, chief amongst which is pressure to deliver results early and quickly. Of course there is no conflict of interest, everyone wants to be productive and deliver value as quickly as possible, but there is such a thing as delivering too fast and this graph broadly helps identify when that is the case. Why it happens is explained by what the graph doesn’t show; all the decisions and micro-decisions made behind the scenes day by day, code commit by commit, far away from the pristine designs that were reviewed, debated and signed off on. These ostensibly time-saving decisions result in short-term shortcuts at the cost of long term velocity by introducing ad-hoc complexity. This turns out to be an inevitable by-product of Agile software methodologies where insufficient time is spent to work out a globally-optimal low-level design. Instead, teams fall into locally-optimal “wells” i.e. implementations optimized to achieve a deliverable in a Sprint, or some arbitrarily demarcated checkpoint. These give birth to the perpetual need for unscheduled and unplanned refactors to climb out of these “wells” in the hopes of converging upon a stable, optimal architecture that would otherwise have been discovered had the appropriate amount of time been spent on design (i.e. the Waterfall SDLC).

Worse still, teams begin to internalize the expectations set by their initial delivery velocity, and begin to cut corners to maintain that velocity. The extent of the shortcuts taken are inversely proportional to the technical knowledge of the overseeing managers and stakeholders. In product driven teams, this inevitably devolves into the familiar spaghetti code with implicit dependencies, global variables, no separation of concerns, and complexity that quickly spirals out of control. Even if the required use-cases are met on paper, there is a lawyer-like interpretation of the requirements that conveniently gloss over the implied requirements (in order of importance): stability, maintainability, extensibility and performance. A dire predicament indeed for a delicate startup.