The topic fo today’s Tech Tuesday is one that every startup I have ever seen struggles with: what to do about technical debt. First off, what is technical debt? The Wikipedia page explains it as “the eventual consequences of poor or evolving software architecture and software development” which result in more effort for subsequent work.This is actually quite good because it makes clear that technical debt doesn’t just result from mistakes (the “poor” part) but also from “evolving.” And as you may recall my advice has been to startups to evolve their technology as they grow.

The direct corollary from the above is: every startups has technical debt. And I mean every. Show me a startup that doesn’t have it and I will show you a company that has vastly over-invested in engineering relative to their scale and relative to product market fit. So if every startup has it, the question becomes, what should you do about it? The answer here is not unlike what you should do with financial debt: don’t try to pay it all back at once but also don’t ignore it and let it pile up further.

Why not pay it all back at once? First, because often that will result in the temptation to do a complete rewrite, which as I wrote before is a very bad idea. Second, even short of a complete rewrite trying to pay it all back will tend to slow down development of new features or even plain old bug fixing too much relative to the needs of customers (and hence the business). The best way to think of it is that there is some natural level of technical debt that exists at all times.

Of course you shouldn’t ignore technical debt either and especially not let it continue to pile up. If you do that, eventually making any change to the system gets so hard that your product becomes frozen. So instead what you need to do is allocate some fraction of engineering at all times to paying back some technical debt. This is one of the key reasons why your total engineering productivity (as measured from a user visible standpoint) will never be as good a year or two into the life of a startup as it was in the early days.

What is the right fraction? The answer is of course: it depends. But as a broad rule if you are a couple of years into it and you are not spending at least about a third of engineering time on rewriting some code (paying back technical debt) you are probably in denial about the extent of your technical debt. And conversely if you are spending more than two thirds of engineering resources on a sustained basis you are probably being overly aggressive.

If you have great examples of different types of technical debt that you have encountered, I would love to hear them. And of course if/how you managed to deal with them.

The topic fo today’s Tech Tuesday is one that every startup I have ever seen struggles with: what to do about technical debt. First off, what is technical debt? The Wikipedia page explains it as “the eventual consequences of poor or evolving software architecture and software development” which result in more effort for subsequent work.This is actually quite good because it makes clear that technical debt doesn’t just result from mistakes (the “poor” part) but also from “evolving.” And as you may recall my advice has been to startups to evolve their technology as they grow.

The direct corollary from the above is: every startups has technical debt. And I mean every. Show me a startup that doesn’t have it and I will show you a company that has vastly over-invested in engineering relative to their scale and relative to product market fit. So if every startup has it, the question becomes, what should you do about it? The answer here is not unlike what you should do with financial debt: don’t try to pay it all back at once but also don’t ignore it and let it pile up further.

Why not pay it all back at once? First, because often that will result in the temptation to do a complete rewrite, which as I wrote before is a very bad idea. Second, even short of a complete rewrite trying to pay it all back will tend to slow down development of new features or even plain old bug fixing too much relative to the needs of customers (and hence the business). The best way to think of it is that there is some natural level of technical debt that exists at all times.

Of course you shouldn’t ignore technical debt either and especially not let it continue to pile up. If you do that, eventually making any change to the system gets so hard that your product becomes frozen. So instead what you need to do is allocate some fraction of engineering at all times to paying back some technical debt. This is one of the key reasons why your total engineering productivity (as measured from a user visible standpoint) will never be as good a year or two into the life of a startup as it was in the early days.

What is the right fraction? The answer is of course: it depends. But as a broad rule if you are a couple of years into it and you are not spending at least about a third of engineering time on rewriting some code (paying back technical debt) you are probably in denial about the extent of your technical debt. And conversely if you are spending more than two thirds of engineering resources on a sustained basis you are probably being overly aggressive.

If you have great examples of different types of technical debt that you have encountered, I would love to hear them. And of course if/how you managed to deal with them.