6 ms·

How many startups are actually killed by tech debt? I saw many successfull companies with shitty software. I had the impression the business part of things ki

by k__ 6y ago

How many startups are actually killed by tech debt? I saw many successfull companies with shitty software. I had the impression the business part of things killed much more companies if they didn't get it right.

29athrowaway 6y ago
Tech debt rarely kills a company, but it does kill teams, in descending hierarchical order. It usually goes like this: Day 1 Stakeholder: "The app is down, what is happening?" Engineering lead: "We are working on it. Do not worry". Day 2 Stakeholder: "The app is down, what is happening?" Engineering lead: "Do not worry, we got this". Fast forward to Day 15: Stakeholder: "Can you explain why the app is down again?" Engineering lead: "We got this" Stakeholder: "That is what you said last 2 weeks ago. We will send someone to take a look at it" External auditor: "wtf wtf wtf. These guys do not know what they're doing." Day 16: Stakeholder: "Say hello to Bob, he is your replacement. Please work with him making sure he has all the context he needs during this transition". Engineering lead: "But, but... it's just technical debt" Stakeholder: "You may leave now"
- xwdv 6y ago
  Why would the app be down that long though? Just take on more technical debt to get it back up and running. If Bob gets the app up and running then that’s all that matters to the stakeholder.
  - 29athrowaway 6y ago
    It doesn't have to be continuously down. It only has to be down often.
    - yardstick 6y ago
      To the end users and management the two are essentially the same outcome: customers leave your non-functional service.
  - daniellarusso 6y ago
    “It works for me.”
- JamesBarney 6y ago
  The engineering lead should be fired. If the problem is technical debt, he should do a proper post mortem and alert the stakeholder to what is required to solve the problem for good.
  - 29athrowaway 6y ago
    Sounds like the reasonable thing to do. But some people are brainwashed to love tech debt: 1) Some people mistakenly interpret "maximizing the work not done" with maximizing tech debt. 2) Power is the ability to make people do what they do not want to do. Saying "no" is a way to exercise that ability. Some leaders become addicted to the feeling of exercising their power. 3) Cohesive groups of people tend to prioritize cohesion over rationality during decision making (i.e.: "groupthink"). Groupthink makes teams unable to make correct decisions or assess risks in a rational manner. Many startups suffer of issues 1, 2, 3. And some even perceive those weaknesses as strengths. When that happens, the only way out is to decapitate the team, punish groupthink and reindoctrinate the team members.
wpietri 6y ago
You could argue that Netscape was killed by technical debt. [1] But I think it's rare to get a case that's clear enough to say. Technical debt gradually reduces product agility and raises costs, so it can be hard to tell the difference between a business failure and excess technical debt. A lot of startups run out of money while trying to find product-market fit, and careful management of technical debt plus the right product processes can get you way more product experimentation. [1] https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
- johnmaguire2013 6y ago
  Except the citation doesn't really argue that technical debt killed Netscape, but rather that it was killed by a rewrite from scratch - the article ends: > If you are writing code experimentally, you may want to rip up the function you wrote last week when you think of a better algorithm. That’s fine. You may want to refactor a class to make it easier to use. That’s fine, too. But throwing away the whole program is a dangerous folly, and if Netscape actually had some adult supervision with software industry experience, they might not have shot themselves in the foot so badly.
  - ArloL 6y ago
    Could one argue that the rewrite being necessary was the result of too much technical debt? Thus the debt did contribute to the failure. But I wouldn't go so far as to call it the sole reason the project failed - that just sounds too easy an explanation.
    - johnmaguire2013 6y ago
      The article cited makes a strong argument for why you should not write from scratch, even with immense technical debt - and offers alternatives.
  - wpietri 6y ago
    Why do you think they rewrote from scratch? The from-scratch rewrite is a classic response to declining productivity. In the metaphor of technical debt, it's equivalent to declaring bankruptcy. As Jamie Zawinski wrote in 1999: "We never distributed the source code to a working web browser, more importantly, to the web browser that people were actually using. We didn't release the source code to the most-previous-release of Netscape Navigator: instead, we released what we had at the time, which had a number of incomplete features, and lots and lots of bugs. [...] The code was just too complicated and crufty and hard to modify [...] By being a cleaner, newly-designed code base, so the theory went, it was going to be easier for people to understand and contribute. And this did get us more contributors. But it also constituted an almost-total rewrite of the browser, throwing us back six to ten months. Now we had to rewrite the entire user interface from scratch before anyone could even browse the web, or add a bookmark." -- https://www.projectseven.com/grafitti/october_2001/zawinski.htm https://www.projectseven.com/grafitti/october_2001/zawinski.... He doesn't use the "technical debt", because that didn't start becoming popular until 2004 or so: https://books.google.com/ngrams/graph?content=%22technical+debt%22&year_start=1800&year_end=2019&corpus=26&smoothing=3&direct_url=t1%3B%2C%22%20technical%20debt%20%22%3B%2Cc0#t1%3B%2C%22%20technical%20debt%20%22%3B%2Cc0 https://books.google.com/ngrams/graph?content=%22technical+d... but if you look at Ward Cunningham's original 1992 description, it sounds pretty congruent: "Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation [...]"
hertzrat 6y ago
Technical debt can slow down product development, which means you can’t iterate quickly enough to compete or to get product market fit. I’m working on a game right now and there’s some debt in there just to get content ready to demo, but everything’s optimized to be easy to change because, otherwise, the whole project will stall. It’s scary trying to find the right balance
woutr_be 6y ago
A part of a product I worked on was killed by the business and outsourced instead. I’m 100% sure this was in fact because of technical debt, even though my team members would disagree. It wasn’t even technical debt in the sense that it was bad code, it was because they prematurely tried to optimise everything, so adding a feature would take twice as long. We also couldn’t add new devs to the project because the team lead’s decision to not document the code, because “code should document itself”. Bugs could only be identified by the dev who wrote that feature because the code was so obscure and undocumented.
- kyawzazaw 6y ago
  What're some good project that has the right balance of documentation? in your opinion I am looking for projects that are very small.
  - woutr_be 6y ago
    I think this depends on a per project basis, in some projects the code can speak for itself, any competent developer would be able to look at the code and understand what’s going on. In projects with a lot of business logic, or projects that require understanding of a specific subject, it’s often better to write comments to clarify what’s going on. Sometimes code alone isn’t enough.
    - kyawzazaw 6y ago
      can you give me any examples
    - JohnBooty 6y ago
      I agree and to that list I'd add: - Performance optimizations (always worth mentioning why you ugly'd up some code for a necessary speedup) - Kludges where you're working around something in an external library or service
- mooreds 6y ago
  > A part of a product I worked on was killed by the business and outsourced instead. I’m 100% sure this was in fact because of technical debt, even though my team members would disagree. I've also had this experience, where a product accumulated so much tech debt (in part, due to my decisions) that it was simpler for the business to outsource the functionality. That wasn't the only reason, but it was a big one. When tech debt sand gets in the software delivery gears, the allure of vendors increases. Sure, the business won't get things exactly like they want them, but they won't have to deal with missed deadlines and degraded functionality either.
zacharycohn 6y ago
Technical debt is a co-morbidity. It's not necessarily the thing that kills you, but it increases the chance problems becomes fatal.
ransom1538 6y ago
"How many startups are actually killed by tech debt?" Basically 0. If you have a good idea - you can overcome. If you have a crappy idea and an amazing engineering team you are doomed.[1] https://randsinrepose.com/archives/1-0/ https://randsinrepose.com/archives/1-0/
- kubanczyk 6y ago
  The article you've linked is not relevant for this thread. It points out that if you have Pitch (the idea), People, Process, Product, you will probably fail anyway. Technical debt, if it's relevant at all, is relevant at much later phase than that.
  - ransom1538 6y ago
    No it points that if you have a crappy pitch (idea) you are doomed. I would reread.
erdo 6y ago
I think I've worked for several - I couldn't say for sure because the first I know about it is when the company has that unscheduled all-hands meeting that I've learned to recognise. The one where they break the news that they've run out of money and your contract is terminated. Too much debt slows you down, and if you don't move quick enough as a start up, the money stops. It's that simple.

by k__ 6y ago

29athrowaway 6y ago

Tech debt rarely kills a company, but it does kill teams, in descending hierarchical order. It usually goes like this: Day 1 Stakeholder: "The app is down, what is happening?" Engineering lead: "We are working on it. Do not worry". Day 2 Stakeholder: "The app is down, what is happening?" Engineering lead: "Do not worry, we got this". Fast forward to Day 15: Stakeholder: "Can you explain why the app is down again?" Engineering lead: "We got this" Stakeholder: "That is what you said last 2 weeks ago. We will send someone to take a look at it" External auditor: "wtf wtf wtf. These guys do not know what they're doing." Day 16: Stakeholder: "Say hello to Bob, he is your replacement. Please work with him making sure he has all the context he needs during this transition". Engineering lead: "But, but... it's just technical debt" Stakeholder: "You may leave now"

xwdv 6y ago
Why would the app be down that long though? Just take on more technical debt to get it back up and running. If Bob gets the app up and running then that’s all that matters to the stakeholder.
- 29athrowaway 6y ago
  It doesn't have to be continuously down. It only has to be down often.
  - yardstick 6y ago
    To the end users and management the two are essentially the same outcome: customers leave your non-functional service.
- daniellarusso 6y ago
  “It works for me.”
JamesBarney 6y ago
The engineering lead should be fired. If the problem is technical debt, he should do a proper post mortem and alert the stakeholder to what is required to solve the problem for good.
- 29athrowaway 6y ago
  Sounds like the reasonable thing to do. But some people are brainwashed to love tech debt: 1) Some people mistakenly interpret "maximizing the work not done" with maximizing tech debt. 2) Power is the ability to make people do what they do not want to do. Saying "no" is a way to exercise that ability. Some leaders become addicted to the feeling of exercising their power. 3) Cohesive groups of people tend to prioritize cohesion over rationality during decision making (i.e.: "groupthink"). Groupthink makes teams unable to make correct decisions or assess risks in a rational manner. Many startups suffer of issues 1, 2, 3. And some even perceive those weaknesses as strengths. When that happens, the only way out is to decapitate the team, punish groupthink and reindoctrinate the team members.

wpietri 6y ago

You could argue that Netscape was killed by technical debt. [1] But I think it's rare to get a case that's clear enough to say. Technical debt gradually reduces product agility and raises costs, so it can be hard to tell the difference between a business failure and excess technical debt. A lot of startups run out of money while trying to find product-market fit, and careful management of technical debt plus the right product processes can get you way more product experimentation. [1] https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...

johnmaguire2013 6y ago
Except the citation doesn't really argue that technical debt killed Netscape, but rather that it was killed by a rewrite from scratch - the article ends: > If you are writing code experimentally, you may want to rip up the function you wrote last week when you think of a better algorithm. That’s fine. You may want to refactor a class to make it easier to use. That’s fine, too. But throwing away the whole program is a dangerous folly, and if Netscape actually had some adult supervision with software industry experience, they might not have shot themselves in the foot so badly.
- ArloL 6y ago
  Could one argue that the rewrite being necessary was the result of too much technical debt? Thus the debt did contribute to the failure. But I wouldn't go so far as to call it the sole reason the project failed - that just sounds too easy an explanation.
  - johnmaguire2013 6y ago
    The article cited makes a strong argument for why you should not write from scratch, even with immense technical debt - and offers alternatives.
- wpietri 6y ago
  Why do you think they rewrote from scratch? The from-scratch rewrite is a classic response to declining productivity. In the metaphor of technical debt, it's equivalent to declaring bankruptcy. As Jamie Zawinski wrote in 1999: "We never distributed the source code to a working web browser, more importantly, to the web browser that people were actually using. We didn't release the source code to the most-previous-release of Netscape Navigator: instead, we released what we had at the time, which had a number of incomplete features, and lots and lots of bugs. [...] The code was just too complicated and crufty and hard to modify [...] By being a cleaner, newly-designed code base, so the theory went, it was going to be easier for people to understand and contribute. And this did get us more contributors. But it also constituted an almost-total rewrite of the browser, throwing us back six to ten months. Now we had to rewrite the entire user interface from scratch before anyone could even browse the web, or add a bookmark." -- https://www.projectseven.com/grafitti/october_2001/zawinski.htm https://www.projectseven.com/grafitti/october_2001/zawinski.... He doesn't use the "technical debt", because that didn't start becoming popular until 2004 or so: https://books.google.com/ngrams/graph?content=%22technical+debt%22&year_start=1800&year_end=2019&corpus=26&smoothing=3&direct_url=t1%3B%2C%22%20technical%20debt%20%22%3B%2Cc0#t1%3B%2C%22%20technical%20debt%20%22%3B%2Cc0 https://books.google.com/ngrams/graph?content=%22technical+d... but if you look at Ward Cunningham's original 1992 description, it sounds pretty congruent: "Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation [...]"

hertzrat 6y ago

Technical debt can slow down product development, which means you can’t iterate quickly enough to compete or to get product market fit. I’m working on a game right now and there’s some debt in there just to get content ready to demo, but everything’s optimized to be easy to change because, otherwise, the whole project will stall. It’s scary trying to find the right balance

woutr_be 6y ago

A part of a product I worked on was killed by the business and outsourced instead. I’m 100% sure this was in fact because of technical debt, even though my team members would disagree. It wasn’t even technical debt in the sense that it was bad code, it was because they prematurely tried to optimise everything, so adding a feature would take twice as long. We also couldn’t add new devs to the project because the team lead’s decision to not document the code, because “code should document itself”. Bugs could only be identified by the dev who wrote that feature because the code was so obscure and undocumented.

kyawzazaw 6y ago
What're some good project that has the right balance of documentation? in your opinion I am looking for projects that are very small.
- woutr_be 6y ago
  I think this depends on a per project basis, in some projects the code can speak for itself, any competent developer would be able to look at the code and understand what’s going on. In projects with a lot of business logic, or projects that require understanding of a specific subject, it’s often better to write comments to clarify what’s going on. Sometimes code alone isn’t enough.
  - kyawzazaw 6y ago
    can you give me any examples
  - JohnBooty 6y ago
    I agree and to that list I'd add: - Performance optimizations (always worth mentioning why you ugly'd up some code for a necessary speedup) - Kludges where you're working around something in an external library or service
mooreds 6y ago
> A part of a product I worked on was killed by the business and outsourced instead. I’m 100% sure this was in fact because of technical debt, even though my team members would disagree. I've also had this experience, where a product accumulated so much tech debt (in part, due to my decisions) that it was simpler for the business to outsource the functionality. That wasn't the only reason, but it was a big one. When tech debt sand gets in the software delivery gears, the allure of vendors increases. Sure, the business won't get things exactly like they want them, but they won't have to deal with missed deadlines and degraded functionality either.

zacharycohn 6y ago

Technical debt is a co-morbidity. It's not necessarily the thing that kills you, but it increases the chance problems becomes fatal.

ransom1538 6y ago

"How many startups are actually killed by tech debt?" Basically 0. If you have a good idea - you can overcome. If you have a crappy idea and an amazing engineering team you are doomed.[1] https://randsinrepose.com/archives/1-0/ https://randsinrepose.com/archives/1-0/

kubanczyk 6y ago
The article you've linked is not relevant for this thread. It points out that if you have Pitch (the idea), People, Process, Product, you will probably fail anyway. Technical debt, if it's relevant at all, is relevant at much later phase than that.
- ransom1538 6y ago
  No it points that if you have a crappy pitch (idea) you are doomed. I would reread.

erdo 6y ago

I think I've worked for several - I couldn't say for sure because the first I know about it is when the company has that unscheduled all-hands meeting that I've learned to recognise. The one where they break the news that they've run out of money and your contract is terminated. Too much debt slows you down, and if you don't move quick enough as a start up, the money stops. It's that simple.