Technical Debt Jenga

Jenga is a popular tabletop game where players remove pieces from a stacked tower and stack them back on top. The voids created by the removed pieces eventually weaken the structure enough that it cannot hold the weight of the pieces now stacked on top. The tower falls, and the winner is the last person to have successfully removed and stacked a piece. We’ll get back to this later.

There’s a tradeoff in getting software out the door quickly -- often times this software will need to be rewritten later, and the cost of doing so is represented by the concept of technical debt (aka tech debt or code debt). There’s a myriad of reasons that a company may incur tech debt, and they are not always attributed to negligence, incompetence, or malice.

technical debt

the cost of additional rework caused by choosing an easy solution now vs. a better approach that would take longer.

Some phrases I’ve heard that relate to technical debt:

I don’t need a code review
They don’t know what they want
They want too much and there’s not enough time
I don’t know how to do this, but I’ll try
This is an important part of our code, and I don’t want to break it, so I’d rather not touch it

I don’t need a code review

Code reviews aren’t about nitpicking on line spacing and variable names. It gives a chance for different viewpoints on a complex system. As a reviewer, I enjoy learning about how a new piece of code will operate and fit into the existing system. As a reviewee, I can reflect back and share what I’ve done, and speak on issues that were encountered along the way.

Some form of code review (and this should change and scale with your company) can help reduce adding more technical debt, but shouldn’t be so cumbersome as to slow your team down.

They don't know what they want / They want too much and there’s not enough time

Scope, schedule, and cost are the three pillars to a project. Nobody should manage all three. Cost is typically fixed because of salaries, but scope and schedule can be adjusted. It’s important to understand that a shorter timeline must come with a reduced scope, while a larger scope warrants an extended timeline.

The requirements to development are never going to be picture perfect, especially in a startup. I’ve found it is best to do some whiteboarding on the key concepts of the problem (while ignoring implementation) with the stakeholders. I like to ask questions like “is this a nice-to-have or a must-have for this release?”

The language used in this session should be more like “What is the number one most important part of this new feature” instead of “Should we use React or Angular?” This article goes into some detail on how to talk about specifications. Like code reviews, the amount of focus and detail should scale with the size of your company.

I don’t know how to do this

All software has bugs. If some software was so simple there were no bugs, it is probably not useful to anyone. It is perfectly ok to incur some debt while getting up to speed on the industry, codebase, or engineering in general. While building an MVP, things won’t be perfect so you’ll have to incur some tech debt.

This is an important part of our code, and I don’t want to break it, so I’d rather not touch it

This piece of code probably has some issues that need to be fixed before deploying anymore new features that rely on it. At some point, debt must be repaid, or you face extra effort and time for future endeavours. If you ignore it now, and keep incurring more debt, your tower will eventually fall.

Unfortunately in business, there is no winner when the tower falls. Technical debt (that I’ve personally introduced) has lead to customers churning. I’ve had to fight fires from a design decision made years ago while trying to get a new feature deployed. Delaying a new feature because of fire fighting is not always preventable, but when the root cause analysis reveals the fire is related to some system that you already knew would fail, you wonder why you didn’t pay that debt earlier.

Not all debt is bad -- sometimes you must optimize for speed and time, and that’s ok. Knowing the trade-offs and understanding balance is more important than never incurring any technical debt.