The Emotional Cost of Tech Debt

There are many occasions where software developers find themselves dealing with code written by others. The nature of humans and complexity is such that they carry along with them far into the future the burden of every previously taken decision - good or bad. And by the nature of complexity, it is bad decisions by definition that are hard to undo or remove and contribute some penalty in time or effort to future problem solving.

It is also in the nature of humans to appease their employers by responding honestly to ostensibly harmless asks such as how long a given task should take to complete. On the surface this seemingly mundane and routine question should not elicit anything but pure cooperation from anyone but those who shirk their professional responsibilities. But the reality of engineering and correspondingly of software development is that it is easier to solve most problems than it is to predict how long it will take to fix them. This tautology akin to the Gödel’s Incompleteness Theorem is a required foundational axiom to understand the underlying physics and chemistry of software development.

There are two main first order effects of this. First, software developers often find themselves in a position where something that would appear to be easy to do ends up taking orders of magnitude more time than expected. In my experience this has been fairly uniform across all skill and experience bands. The second is that developers when given the choice between revising their estimates and cutting corners to meet that deadline will choose to eventually - if not immediately - cut corners to deliver as early as possible.

It turns out that the thing that makes software unpredictable is complexity, and the first sacrifice on the altar of deadlines is simplicity. And so an unholy downward-spiral chain reaction occurs causing ever more complexity and continuous “crunch time”. Deployment velocity tends toward zero. Feature development time tends toward infinity. This is a death sentence for the quality of software produced by an organization.

The solution is not technical. The fix for this lies in understanding human psychology and the cost of unrealistic expectations. Software Development Managers (SDMs) must balance carefully the overtly measurable delivery timelines against the discreet, latent accumulation of complexity in the form of technical debt. Leaders must understand how to move forward with deliberation, intent and purpose, to root out from the organization and the culture people who look to extract as much short term value from the team as possible before leaving an unrecoverable mess for others to clean up. And lastly a culture of trust must be afforded, earned, and built to allow software developers to adopt the true nature of Agile Software Development which states as its core tenet: “Responding to change over following a plan”.