Embracing Technical Debt in a Startup

Whether you are a member of “Lean Startup” cult or simply a sane entrepreneur, it’s a common pattern to have an MVP (minimum viable product) as your first release. [Almost] no one argues with that.

Everyone agrees that it’s way more important to build the right thing than to build the thing right. Everyone except every alpha-developer out there.

- Whaaat!? No unit tests!? I’m out!
- Copy-pasting code!? That’s unmanageable!
… and on an on

As a developer (I should probably start adding a “former” qualifier) I can totally relate to that. I’ve read a bunch of books and articles on writing manageable, testable, beautiful code. I’ve developed piece-of-art frameworks just to lose interest in the final product before I even got to doing any meaningful work on its immediate logic. I’ve spent days creating methods that will never get called, interfaces that will be implemented only once, class hierarchies with no immediate purpose.

Luckily for me as an entrepreneur (and likely the reason why I could never be a very good programmer) I have slightly more interest in releasing stuff than in obsessing over the beauty of the underlying architecture.

That was the reason why it took me less than a month from idea to launch for AdDuplex while my then potential competitor (now a friend) was honing his feature set and architecture.

The first version wasn’t just an MVP (I only knew a basketball/sports and a Microsoft meaning of the acronym back then). It was also a QVI — an acronym I’ve just invented for Quickest Viable Implementation. It used frameworks and code that I knew weren’t suitable for running an ad server. It had no unit tests, no dependency injection, no beautiful class structure. I’m pretty sure no one would hire me as a developer if I’ve shown them the code during a tech interview.

But it was out. It worked. People loved it. And it changed my life forever.

Opportunity cost

Four years later we are still here and as strong as ever. There’s very little (none?) of my initial code left in the codebase. It definitely cost us more time and money to undo all my code crimes than if I put more thought into it from the get go. My (naïve) architectural decisions will haunt us for a very long time. Maybe even forever. Maybe they will even be a reason of our eventual demise (*knocks on wood*). But the main reason we are alive and kicking today is my acceptance of the sucky code that does the job 4 years ago.

Just recently we’ve stumbled a bit (and by “a bit” I mean a lot) with meeting an internal deadline for an update we were working on. The main reason for the delay was that dev team decided that implementation of this new feature was a good trigger to refactor related parts. After all copy-pasting the code for the third time isn’t kosher at all. I was probably wearing my developer hat at the time and for some reason this made perfect sense to me. But as the deadline slipped and slipped I started to think about the bigger picture.

We had two ways to address the problem. We could either do a quick and dirty implementation, release the update and then invest into (re)making it right (W1). Or we could try to do it perfectly right away (W2). This is not a “right product problem”. The end product (as far as the customer is concerned) is the same. This is purely a problem of getting deeper into technical debt or addressing technical debt before we do the new feature.

It is pretty clear that doing things the first way would cost more. In other words Cz < (Cx + Cy). It is also clear that we would have the feature earlier the first way (Cz > Cx). What is not clear is how the opportunity cost (OC) compares with the cost of refactoring (Cy).

And the truth about that is: a) you never know; b) it could mean the difference between life and death of your product/company.

While the cost of refactoring could be anywhere from low to high but finite, the cost of missed opportunity could very easily be infinite. This is what bit my competitor-friend 4 years ago. And it is especially important for a highly focused (read non-diversified) startup. You can always afford to pay your technical debt back, if your product rocks on the business side, but you can never recoup a missed opportunity with your beautiful code.