When we don’t write the code that we know we should write, we incur tech debt.
When we write code that we know we shouldn’t, we incur tech debt.
When we write code in a way that we know could be better, we incur tech debt.
How it starts…
We make these decisions because they’re quick fixes to our problems right now. Instant gratification satiates our immediate concerns at the expense of our future selves (and others).
When we incur tech debt, we’re figuratively running up the balance on our tech credit card. At first, we get a quick win without any obvious drawbacks. “I’ll pay it off right away!” we promise ourselves.
But before we refactor, we come up against another super urgent problem. “It’s also small… let’s just do this one more time,” we convince ourselves.
“It’s not like I’ll let this get out of control.”
We know how this story turns out…
“But it isn’t our fault! We’re only developers, after all. With constant pressure to deliver working software, we just have to take shortcuts. Besides, employee turnover is so fast in this industry that I’ll be long gone before I need to worry about the effects, anyway.”
Like financial debt, tech debt comes on slowly and imperceptibly. As it grows, it gradually reduces our ability to do things that we need and want to do, because ultimately we become slaves to the interest payments that our debt master demands. Soon, we can’t create new features, or any new features we manage to squeak out are riddled with bugs. The longer the debt accumulates, the harder it is to bite the bullet and start cleaning things up again. We can’t innovate or invest for the future, because we’re swamped just trying to keep up with the maintenance payments.
While in maintenance mode, we’re stagnating at best. More likely, our software health continues to degrade.
Eventually, our competitors are beating us so badly that they put us out of
our misery business.
We’ve all incurred tech debt
I’ve heard it said that the ancient Israelites used the same word for “sin” and “debt”. It may be true, but I couldn’t verify it after exhaustively searching Google for 3 minutes.
But debt and sin have been closely linked in Christian theology going back to its origins.
The wages of sin is death.Romans 6:23
And our tech debt doesn’t just impact ourselves. It affects everybody in the company. Really, if you think about it, it impacts everybody in the world – now and going forward – since what we produce directly contributes to the joy, efficiency, health, and more of the aggregate human population.
Is there a verse related to this, too?
Wherefore as by one man sin entered into this world, and by sin death; and so death passed upon all men, in whom all have sinned.Romans 5:12
Just replace “sin” with “tech debt”… I didn’t because I didn’t want to write blasphemy.
Confession and Rectification
Today is Ash Wednesday, a day that marks the annual period of Lent, which Catholics devote to confession of sins, sacrifice, and penance, leading up to the eventual rebirth and fresh start celebrated at Easter. It’s a valuable 40 days in which we can reevaluate and make ourselves aware of our mistakes in the past year so that we can aim to do better going forward. We are to remind ourselves of things we did that we know we shouldn’t have done, and of things that we did not do that we know we should have. Without this rhythmic focus each year, it becomes more likely that our guilt and bad habits continue to take control of us, like growing financial debt causes us to worry and takes over our economic lives, and like growing technical debt gives us guilt and worry and takes over our software.
Many of us work under different Agile setups, with similar rituals to analyze and continually improve the Agile process itself. But how many of us also have periods of time explicitly set aside for nothing other than reviewing old code? Code that we know is there, gnawing at our developer conscience. Code that we hope our peers don’t discover, because we know they’d judge us… and rightfully so!!
Maybe it’s better if we’re given the opportunity to confess our technical sins in relative privacy, perhaps to a more talented and experienced developer… somebody who we look up to as a sort of mentor……. a coding father figure, if you will.
“I made took a shortcut here, and I’m sorry about it. What can I do to make it better and get a fresh start?”
“Write two integration tests and nine unit tests. It will be okay. Go and code better.”
At what sort of frequency should this happen? No clue… I’m still just a baby figuring things out. I just know that it should happen. It’s important enough to make it an explicitly set-aside ritual in our sprints… as critical as daily stand-ups and sprint retrospectives.