[idank]

The title the author chose does a bit of injustice to the contents of the post.

The post uses a lot of words to describe an understanding that experienced engineers and managers should have. Technical debt is a trade off. It exists in nearly all software of decent size as it's being developed. It is vital both for management and engineers alike to keep it at a reasonable amount, or you'll wake up one day with something that can't release new features, function, scale or be maintained.

It is also worth stating that tech debt can have little to no siginifcance to the success of a startup.

[wolco2]

Technical debt starts to matter when the initial project changes focus or patches start mountig.

These days rewrites are popular. They make sense in some cases (when the project is smaller or introducing new framework). But in others where the original developer and business people have left and no one knows exactly how things work aside from they need to continue to do the same. In those cases fixing technical debt is extremely important.

A startup is more likely to fall into the above category if they ignore their technical debt because rewrites are hard and messy.

[Mertax]

Seems to me that technical debt needs to be dealt with as a function of the revenue the company/product is bringing in.

The wisdom comes from timing the investment so it’s not destroying the “mature” product due to entropy or strangling the new product due over engineering.

Startups do seem to have bigger issues than technical debt to deal with. Because relatively speaking, there are bigger mountains to climb early in the startup’s development.

[kubanczyk]

It is moreover not entirely unworthy to state that tech debt can have little to no siginifcance to the success of the founder of a startup. /s