I see a lot of answers about how it's not technical debt that kills startups, it's failure to address customer needs. But I don't think these two are so different.
My definition of technical debt would be "problems in the code base that make it harder than it should be to do work," whether that work is adding new features, fixing bugs, scaling up, etc. The startup that can implement new features quickly because their code base isn't a disaster is more likely to succeed. They can try out new features quickly, seeing what customers respond to.
Customers need things like uptime, minimal bugginess, quick bug fixes, etc. Technical debt reduces uptime, increases bugginess, and makes it harder to fix bugs.
I think it would be hard to point at a startup and say "technical debt killed it". In most cases I imagine there are many inter-related causes of failure, but an inability to quickly add new features, fix bugs, and keep the system stable can't be a good thing!
Customers need things like uptime, minimal bugginess, quick bug fixes, etc.
You've basically elevated these items to the top of the list, above all other attributes, and declared them more important to all customers.
Customers will pay/use a product that delivers value. The items you listed subtract from that value but they may or may not eliminate it. It depends on the product, and how valuable those items are to the customers.
Edit: I'll add an example. Let's say you like video games. There's a particular game that you love to play. Do you love that game because "it's stable, has minimal bugginess, and the developers release patches on time"? Probably not. You love it because of the gameplay/storyline/graphics/whatever. If the game is unstable, that's irritating, and makes it less enjoyable.. but that doesn't change what you love (value) about the game.
You've basically elevated these items to the top of the list, above all other attributes, and declared them more important to all customers.
No I didn't. I'm just saying that these things are also important to customers. Churning out tons of broken features on top of a constantly crashing/unavailable system is not a winning formula for success in many markets.
It might work to some degree for free consumer-facing apps (like Twitter), but for many other sectors reliability and data integrity are very important factors (like any B2B product).
a situation in which someone or something must do or have something
Saying "these things are also important" and that it depends on the type (twitter vs b2b) of product is a lesser statement than your original statement. If you want to tone down what you originally said that's fine.
The comments are interesting, but the closing one by a Mark Peterson again goes to the bottom line of unaddressed technical debt by putting a date on the best known general technical problem:
Friendster failed in the summer of 2003 when it never took less than a minute to log into the site. Where it never took less than a minute to visit any page. Even pages that should/could have been static.
Debate about any missing feature after summer 2003 is less than moot.
Especially since added features or allowing viewing by the not logged in would tend to further slow down the site.
Comments
I see a lot of answers about how it's not technical debt that kills startups, it's failure to address customer needs. But I don't think these two are so different.
My definition of technical debt would be "problems in the code base that make it harder than it should be to do work," whether that work is adding new features, fixing bugs, scaling up, etc. The startup that can implement new features quickly because their code base isn't a disaster is more likely to succeed. They can try out new features quickly, seeing what customers respond to.
Customers need things like uptime, minimal bugginess, quick bug fixes, etc. Technical debt reduces uptime, increases bugginess, and makes it harder to fix bugs.
I think it would be hard to point at a startup and say "technical debt killed it". In most cases I imagine there are many inter-related causes of failure, but an inability to quickly add new features, fix bugs, and keep the system stable can't be a good thing!
Customers need things like uptime, minimal bugginess, quick bug fixes, etc.
You've basically elevated these items to the top of the list, above all other attributes, and declared them more important to all customers.
Customers will pay/use a product that delivers value. The items you listed subtract from that value but they may or may not eliminate it. It depends on the product, and how valuable those items are to the customers.
Edit: I'll add an example. Let's say you like video games. There's a particular game that you love to play. Do you love that game because "it's stable, has minimal bugginess, and the developers release patches on time"? Probably not. You love it because of the gameplay/storyline/graphics/whatever. If the game is unstable, that's irritating, and makes it less enjoyable.. but that doesn't change what you love (value) about the game.
No I didn't. I'm just saying that these things are also important to customers. Churning out tons of broken features on top of a constantly crashing/unavailable system is not a winning formula for success in many markets.
It might work to some degree for free consumer-facing apps (like Twitter), but for many other sectors reliability and data integrity are very important factors (like any B2B product).
Customers need things like ...
Definition of need:
a situation in which someone or something must do or have something
Saying "these things are also important" and that it depends on the type (twitter vs b2b) of product is a lesser statement than your original statement. If you want to tone down what you originally said that's fine.
Thanks, yes it's hard to point out one specific example of a startup, because it can be an inter-related cause as you mentioned.
Though someone else here mentioned how friendster lost their game due to technical debt:
I looked it up and it looks like that indeed it was an issue.
http://highscalability.com/friendster-lost-lead-because-fail...
Yes, that is one of my concerns usually. It's good to go fast and build more, but not to an extend where it slows the process down on longer run.
Thanks for that link.
The comments are interesting, but the closing one by a Mark Peterson again goes to the bottom line of unaddressed technical debt by putting a date on the best known general technical problem:
Friendster failed in the summer of 2003 when it never took less than a minute to log into the site. Where it never took less than a minute to visit any page. Even pages that should/could have been static.
Debate about any missing feature after summer 2003 is less than moot.
Especially since added features or allowing viewing by the not logged in would tend to further slow down the site.