Technical Embezzlement - Opaquely Creating Technical Debt

I arrived at the term and definition of technical embezzlement during a conversation with Mark Kennedy. We were discussing technical debt and how to manage it.

Wikipedia defines technical debt as:- Technical debt ... is a recent metaphor referring to the eventual consequences of poor system design, software architecture or software development within a codebase. The debt can be thought of as work that needs to be done before a particular job can be considered complete or proper. If the debt is not repaid, then it will keep on accumulating interest, making it hard to implement changes later on. Unaddressed technical debt increases software entropy.

An example of where technical debt is typically created is when management place too many constraints; time, people or scope constraints on the development team. Management may do this in order to speed up time to market in order to gain a competitive edge or save more lives. Teams then trade technical debt for shorter delivery schedule.

There's nothing wrong in this trade off. It's a valuable tool providing it's transparent and agreed with the organisation. However when the organisation has trusted employees with it's code, is striving for sustainable value, and yet has no idea that this trade-off has taken place, technical embezzlement has occurred. The organisation will have to pay real money in terms of the team salary or contract costs to address the debt and any interest accrued.

Fear Can Lead to Technical Embezzlement

Technical embezzlement can be one of the symptoms of a fear based culture. A culture where others see managers punish those who highlight the issue of being overly constrained. Where managers don't address the constraints or accept the technical debt resulting from those constraints. In these organisations although the act of creating technical debt is at the team level the technical embezzlement is at the organisational level.

Sparkly Ball Lead Technical Embezzlement

As a software engineer or product manager there's nothing as exciting as shipping a new feature. It's why most of us do what we do. Unfortunately this can lead to us taking short cuts in building out each feature's sustainability. We just want to move on to building the next sparkly ball. When we do this knowingly we're short changing both our organisation and our customer. Even though it's without malice, technical embezzlement has occurred. Everyone in the organisation needs to be vigilant for this because as it's so tempting for many of us. This is where self-discipline plus human and automated guardrails can help. We should look to use practices such as acceptance test driven development, pair-programming and code analysis tools to prevent technical embezzlement occurring.

Danger of Misaligned Reward System

On the same lines as above but importantly different is having a misaligned reward systems. One which encourages technical debt without the organisation realising it. An example is an organisation wanting to ship sustainable value but only rewarding shipping features, with no balancing reward for quality. The organisation has then created a reward system that encourages teams to trade technical debt for speed without realizing it. Arguably no technical embezzlement has occurred only poor leadership at the organisation level.

The Power of Naming

Before now there was no easy way of referring to the act of knowingly creating technical debt without gaining agreement.

My hope is to discourage this poor practice by naming it with a phrase that has the appropriate level of social stigma attached. I think Technical Embezzlement gets us there.