Technical Debt Is Cholera, not Quicksand

Technical debt (TD) – the compromises we make to get stuff out the door – is more often acknowledged and occasionally quantified. We categorize the inefficiency and difficulty working with it—the “interest” on the debt—as an unfortunate cost. Fixing technical debt (paying down the “principle”) competes for resources with new development and tangible defects

The common TD horror story is changing the behaviour of badly-coded modules1. For example, spending hours adding a simple variation to an existing implementation, which has never worked consistently (and never been fully tested – let alone built for extension or reuse), is dangerous as well as frustrating. Without tests or clear documentation, we are never sure what good behaviour is, so extending that behaviour is often an exercise in faith2

In analyzing technical debt, we tend to mythologize it:

Poorly-written code and poor design is not just passively bad (causing more work only when we work on or nearby it); it is actively bad as it infects new, unrelated code as well as infecting developers themselves

At the integration level, we are forced to accommodate existing TD by pandering to its non-standard parameters, side effects, etc. when we interact with it. If it does not participate in normal error handling, writing tests and investigation test-failure are likewise infected3. The calling code must be malformed to match the bad interface, and we must document that knowledge for each bad interface or relearn it over and over

At the introductory level (barring specific guidelines and approved examples), starting developers will use bad code as a template as easily as good code because they have no way to know the difference. The bad code uses developers to reproduce itself the same way cancer uses cellular reproduction As they learn, while developers will be able to recognize bad code, and they will see that their organization tolerates it

At the systemic level, TD dulls developers. The longer we live with bad code, we become attuned to allowing it. We might consciously or subconsciously choose to avoid fixes and enhancements in TD areas because it’s easier and safer.
The technical debt area becomes unattractive even if they would normally be the best place architecturally. Developers who do not understand the TD, either where it lives or its danger, will think the architect is a fool. Developers who understand the reasoning will grudgingly agree with the prohibition, but not happily

And at the organizational level, TD makes developers leave either because they have to work with it (and it makes them feel dirty), or because they are not allowed to fix it

We cannot fix all technical debt. We need to evaluate the cost of fixing it in compared to new features, new products, etc. However, we need to evaluate all its costs, not just the mythological ones #

  1. Good code is all alike; bad code is bad in its own way 

  2. or hubris 

  3. perhaps technical debt is more like zombies 


Now read this

The Detail-Backfill Pattern or DataLoader Before It Was Cool

While optimization is often premature and, therefore, the root of all evil1, using an efficient design for data access is choosing a good path rather than paving a bad one. A common task for APIs is to retrieve a “page” of master rows... Continue →