Why is everything so hard?
Part 1: Tech Debt
Are you ever been baffled by how long it takes your seemingly-competent dev team to complete the seemingly-simplest tasks?
Why do some teams sail through difficult challenges while others stumble and struggle to add a checkbox?
The answer, more than likely, lies in technical debt.
Technical debt is a term coined by Ward Cunningham, inventor of (among other things) the Wiki. It is a useful metaphor when talking about development.
When we build things fast, we can get them working quickly, but the design of the system may not be very good. Early iterations of the code may take some shortcuts. Or the code may not accurately model the underlying concepts that eventually emerge. As a result, when building on top of that code, extra mental effort is required.
Think about how much more difficult it is to prepare a meal in an unfamiliar kitchen, where the dishes haven’t been washed, the knives are all dull, and the sauce pan is, for some reason, hiding in the cupboard with the coffee mugs. This is how developers feel building in a code base that is fraught with debt. It’s harder to get things done, and so everything takes longer.
Technical debt is responsible for the additional time it takes to prepare a meal in a dirty kitchen–it’s the cost of disarray.
To put it back into financial terms, as Martin Fowler writes, “The extra effort that it takes to add new features is the interest paid on the debt.”
So, tech debt is bad?
If we’re going to indulge in a metaphor from finance, perhaps it makes sense to receive our advice not from software engineers but from financial gurus.
Ramit Seth, in his book “I Will Teach You To Be Rich” argues that, although credit cards get a bad rap, if used wisely they can be an excellent financial decision. “If you pay your bill on time,” he write, “they’re actually a free short-term loan.”
By taking on a bit of debt, we have things sooner. Rather than waiting to save thirty thousand dollars, we take out a loan and we can have the car now. If we have the car now, we can use it to get to work. Wisely used, the asset that we own sooner by taking on debt enables us to make more money than we spend on interest.
But we have to be mindful of debt, and make sure that we are paying it down responsibly before forging ahead with more costly purchases, else we may find ourselves devoting a large chunk of our purchasing power to paying off the interest.
Talking about tech debt
If your team seems stressed out and slow, it could be useful to start a conversation about technical debt. The metaphor of debt gives us a shared vernacular, which allows us to plan, and to make smarter decisions a group . For example, if we took some debt on in an area of an application that we’ll be working on a lot for the next few weeks or months, we’ll want to be sure to set aside some time at the start to pay down that debt via refactoring, investment in dev-ops or writing documentation. The larger a project is, the longer it has the potential to take, the more important it is that we set some time aside at the beginning to pay down the debt. Doing so will mean that the project ultimately completes in less time. For smaller projects that will deliver greater value and/or are time-sensitive, we might allow debt to exist, or perhaps even decide to take on some debt to complete them quickly.
Before we can make these decisions, we need to know how much debt there is. Here are some good questions to get the conversation started:
Is it easy to make changes to the code without breaking things?
Is the code-base well-documented?
Is the code readable? Is it simple to understand?
Does the code do a good job at reflecting the objects or concepts that it is modeling?
Is the code well tested?
Could we move faster if we took some time to refactor?
How long does it take to re-compile the code and refresh a page in a local development environment?
How easy is it to set up a local development environment to test scenarios for common issues?
If the engineering team is shaking their head or looking at their feet during this talk, it may perk them up to suggest that we slow down and take some time to refactor or write better documentation.
If they look like they want to cry, it might be time to declare tech-bankruptcy and start over with a new code base.
With our newfound “debt-consciousness,” decisions about taking on and paying down debt can now be made as a team. Resolve to be responsible with your tech debt, and never to make the same mistakes again.
The limits of the metaphor
Like all good metaphors, the tech debt metaphor breaks down at some point. Unlike monetary debt, tech debt is qualitative and multi-dimensional–it can’t be measured with a single number.
But if your team’s velocity has slowed to a crawl, it may be time to acknowledge the cost of forging ever forward and take some time to get your tech in order. The concept of tech debt can help get you all on the same page.
This post is the first part of a series called “Why is Everything so Hard?” where we use the power of metaphor to attempt create a shared vernacular, in the hopes of fostering greater understanding between product and engineering.