Using Technical Debt As A Time Machine

See your startup’s history by looking at its technical debt. Where has your startup been and where is it going?! To the untrained eye the below graphic may just look like an ordinary line graph featuring a company’s repository size and the amount of technical debt in the repo. But, if you look more closely this information actually begins to tell a narrative. The repo-to-tech debt comparison helps illustrate the historic journey on which a startup has been. the history of Bliss’ repo size and technical debtIf you look at the graph you’ll see that my co-founder, Ian, and I started Bliss in early 2015. For the first several months we bootstrapped the company, working night and day to get the product built. In the early days of Bliss we made the conscious decision it was more important to prove we could obtain paying customers and have a strong growth rate than it was managing tech debt. For the first couple of months we focused on shipping features quickly rather than over engineering every little aspect of the new product. Come July, as you can see in the graph, the amount of code we were producing began to flat line a bit. Myself and Ian were running around San Francisco meeting and pitching investors to secure our seed round. Fundraising is a timely, but necessary process, and it resulted in less code being shipped than previous months. After the summer we got back on a decent trajectory, however, we were still operating with a high amount of technical debt — an amount that wouldn’t be sustainable for the long run. With our sites set on adding new full-time developers to the team we needed to get our technical debt to a level which we felt comfortable with so they could jump into a consistent code base and add value quickly. Strategic Shift Come October, our strategy changed. Having raised some initial capital, we were able to hire our first two full-time engineers — Jace and Mikey — and run a more balanced, long-term approach to our code base. You can see a huge spike in the size of our repository, while the amount of technical debt remained at a level sustainable for future growth. It took us several months, but, as of last month, we’re now operating at 20% technical debt — a level of technical debt all stakeholders of Bliss are comfortable with to ensure we’re not jeopardizing our future. Granted, we still have bugs, but by managing our debt now we’re materially reducing the amount of time and money we spend on refactoring (or throwing away) code in the future. Moreover, future developers will be happier not having to clean up other peoples tech debt. No company ever gets to 0% technical debt. It’s just not possible, nor is it worth your time trying to get to perfection. As you can tell I think technical debt is fascinating. It plays an important role in a company’s ability to grow efficiently and by tracking its progress over time you’ll capture an interesting and valuable picture of your company. Does your technical debt tell a story? Share it with [email protected]/* */ I’d love to hear about it (and perhaps feature it in a future blog to help educate the masses).