Let’s face it. You have debt, I have debt, the entire tech world is built on technical debt. What’s the worse thing that can happen when all of our software is built off a pile of technical debt? Well, would you drive on an overpass built with the modeling clay, that was used to green light that project? Ya, didn’t think so. In the beginning stages of building a product, it's easier to cut corners and make quick decisions. No one sits there and says to their investors, “We understand you want a quick return on the nice big check you wrote, but we are trying to figure out if the platform should be made using blockchain or Rails 5.” (Yes, I know those are VASTLY different things, work with me here).
CAST Software found the average per-line cost of technical debt to be $3.61, and for Java code, a staggering $5.42.
You want to build a platform, go to market quickly and get that sweet, sweet validation that users actually want what you built. I’m not here to kill your dreams or to tell you to move slowly. After all the tech industry is famous for “fail fast.” What I want to suggest is that as soon as you go to market with viable product, start thinking through those long term consequences. That time you choose X, when you really knew Y would have been a better long term solution. Do you have time to clean up that 53 line function in your Android app? Can that unit test use a few more, obvious, edge cases? You and I both know the resounding answer is: “YES!”
The rest of this post is broken into two parts. Part 1 is for product people. Part 2, is geared towards you magnificent engineers. Read both, one or none, I’m a “blogger” not the law, I don't control you.
Part 1:
Since you’ve inherited some amount of technical debt in your current project, here's how to deal with it. Allocate time each sprint to fixing some of that debt. Don’t try fix the debt in a single hackathon. And for the love of god don’t wait for a client to find an issue that could have been resolved by addressing the debt sooner. Most importantly make all engineers take part in addressing the technical debt. I don't care if they are senior. If they write code they should fix code. Don't want to fix code? Don't build brittle code. Everyone should feel the pain of technical debt. That way, everyone on your team will be more likely to make better decisions when writing future code. Also, every engineer will see more of the code base and get more context around that next ticket they are working.
Part 2:
Paying off technical debt does two things. Probably more, but I have other things to do so we’re keeping this short. First, when you take that next job at another startup, you won’t be leaving an incomprehensible code base that the new guy has to decipher. And second, as your company scales up and brings on more clients, (and why wouldn’t it? Look at the shiny new thing you built) the shaky initial code will probably not be able to handle the increase in loads. Now clients, and leadership are unhappy and your stuck debugging code at home on a Saturday and not out on the mountains skiing. The latter seems more fun to me, but you do you.
Think about it. You go to your new job and the person your replacing didn’t pay off some (notice not ALL) of their platform’s technical debt. Well now, you have 40 hours with of Jira tickets for that week AND you have to pick through the code at a snail’s pace. You’re not happy, your PM isn’t happy, and your leadership team isn’t happy. People like being happy. Leave good code, get good code. Every company is guilty of ignoring technical debt. It’s not new and sexy. But like that annoying debt collector call at 2am, your technical debt isn't going anywhere. Pay it off.
And there you have it. Another blog post from someone with a keyboard. We laughed, we cried, and we learned that Alexa has been programmed to call out the person who broke the build.