4 ms·

I don't know a real number but my guess and personal feeling, having failed and succeeded, is that technical debt accounts for very few failures. Wrong product

I don't know a real number but my guess and personal feeling, having failed and succeeded, is that technical debt accounts for very few failures. Wrong product fit, ignoring customers, failing to market properly, failing to ship etc all are far more likely to cause the demise of a startup. Also, I would say to much concern over technical debt can cause failure. I personally lost what I conservatively would say was 30% of our net revenue last year letting my prior lead dev address technical debt that never benefitted a single client and that in areas we have now replaced (or are in process of replacing) entirely in the product. I am as much (if not more so) to blame as he was because I approved the time.

Yadi 11y ago
Indeed, there are lots of factors to lead to a product fail. Though, I'm really curious, mind if I ask what sorts of technical debt you had in your startup that led to such massive slow-down in the process? Were the debts among any of these: * Documentations for on boarding devs. * Lack of tests. * Delayed refactoring. * Lack of alignment to standards.
- davismwfl 11y ago
  So in my case, I will share that we screwed up last year by addressing things that didn't benefit our clients. We had probably 20 features that should have been developed that would have benefitted our clients. Instead I allowed our team to focus on scalability (which wasn't really an issue at the time), plus we migrated databases, added ElasticSearch for full text search (which wasn't an issue yet), reengineered a number of features, all of which were working, although maybe not ideally. Also, almost everything you mentioned is on my list of WTF was I thinking. We wasted time adjusting code to meet new standards, adding tests to things we knew we were changing, adding scalability to places we had no scalability issues with (yet), adding new interfaces/code in places where something "might" happen etc. None of these changes benefitted a client directly, so IMO we lost money on every one of those initiatives. The reality is a lot of the code we "brought up to standards" was rewritten anyway when we started adding features and refactoring the old code to interface these features. I also allowed the team to create their own modules instead of extending some existing node.js modules that existed in the community, which to me was a waste when I saw what we did. We would have done better to extend the community modules and open source them back to the community. As for documentation, honestly, we have pretty good documentation, although I wouldn't say it is without issues. Overall I considered last year, the year of the "it might happen" screw ups. What really pissed me off is I spend a huge amount of time advising clients not to touch old code unless they know it is causing them a problem now or can be proven to cause an issue when testing against a new requirement. Yet, I still failed to follow my own rules, shit happens.
  - Yadi 11y ago
    Thanks a bunch! You're a champ. Yeah sometimes making these sorts of decisions could easily lead to big pitfalls on the way. Regarding this part: > "I also allowed the team to create their own modules instead of extending some existing node.js modules that existed in the community, which to me was a waste when I saw what we did." This is technical debt as well by the definition of Wikipedia and some 101 CS books. Having enough contribution from a community could always be better of being used, unless that part of the technology is propriety in the product.
    - davismwfl 11y ago
      You are welcome. I totally agree I screwed the pooch and having 20 years of experience didn't save me. Ironically I had made sure we were giving back to the community but missed some opportunities that would have saved us time and money. Oh well, this year we will add the code to the modules we use. It is on our to do so we remove unnecessary dependencies we added.
meric 11y ago
What if the company is in a tight market and it differentiates itself by being reliable and be able to constantly implement new features as well as competitors features quickly? I would assume taking on technical debt, unless you can bankrupt your competitors in one blow, is suicide since in the long run whoever have the least technical interest payments wins. That assumes the company has done those four things you mentioned solidly.
- davismwfl 11y ago
  I feel you are talking about a situation that rarely exists. It does happen at least somewhat when you see a large incumbent versus a startup, but in those cases a startup is generally nimble and has a fighting chance. IMO, if technical debt is what destroys your startup then you probably so poorly understood the customer problem early on that you engineered a solution that was going to fail either way. In all the companies I help I almost always see bad technical decisions, but their marketing is what is hurting them the most not their tech debt.

Yadi 11y ago

Indeed, there are lots of factors to lead to a product fail. Though, I'm really curious, mind if I ask what sorts of technical debt you had in your startup that led to such massive slow-down in the process? Were the debts among any of these: * Documentations for on boarding devs. * Lack of tests. * Delayed refactoring. * Lack of alignment to standards.

davismwfl 11y ago
So in my case, I will share that we screwed up last year by addressing things that didn't benefit our clients. We had probably 20 features that should have been developed that would have benefitted our clients. Instead I allowed our team to focus on scalability (which wasn't really an issue at the time), plus we migrated databases, added ElasticSearch for full text search (which wasn't an issue yet), reengineered a number of features, all of which were working, although maybe not ideally. Also, almost everything you mentioned is on my list of WTF was I thinking. We wasted time adjusting code to meet new standards, adding tests to things we knew we were changing, adding scalability to places we had no scalability issues with (yet), adding new interfaces/code in places where something "might" happen etc. None of these changes benefitted a client directly, so IMO we lost money on every one of those initiatives. The reality is a lot of the code we "brought up to standards" was rewritten anyway when we started adding features and refactoring the old code to interface these features. I also allowed the team to create their own modules instead of extending some existing node.js modules that existed in the community, which to me was a waste when I saw what we did. We would have done better to extend the community modules and open source them back to the community. As for documentation, honestly, we have pretty good documentation, although I wouldn't say it is without issues. Overall I considered last year, the year of the "it might happen" screw ups. What really pissed me off is I spend a huge amount of time advising clients not to touch old code unless they know it is causing them a problem now or can be proven to cause an issue when testing against a new requirement. Yet, I still failed to follow my own rules, shit happens.
- Yadi 11y ago
  Thanks a bunch! You're a champ. Yeah sometimes making these sorts of decisions could easily lead to big pitfalls on the way. Regarding this part: > "I also allowed the team to create their own modules instead of extending some existing node.js modules that existed in the community, which to me was a waste when I saw what we did." This is technical debt as well by the definition of Wikipedia and some 101 CS books. Having enough contribution from a community could always be better of being used, unless that part of the technology is propriety in the product.
  - davismwfl 11y ago
    You are welcome. I totally agree I screwed the pooch and having 20 years of experience didn't save me. Ironically I had made sure we were giving back to the community but missed some opportunities that would have saved us time and money. Oh well, this year we will add the code to the modules we use. It is on our to do so we remove unnecessary dependencies we added.

meric 11y ago

What if the company is in a tight market and it differentiates itself by being reliable and be able to constantly implement new features as well as competitors features quickly? I would assume taking on technical debt, unless you can bankrupt your competitors in one blow, is suicide since in the long run whoever have the least technical interest payments wins. That assumes the company has done those four things you mentioned solidly.

davismwfl 11y ago
I feel you are talking about a situation that rarely exists. It does happen at least somewhat when you see a large incumbent versus a startup, but in those cases a startup is generally nimble and has a fighting chance. IMO, if technical debt is what destroys your startup then you probably so poorly understood the customer problem early on that you engineered a solution that was going to fail either way. In all the companies I help I almost always see bad technical decisions, but their marketing is what is hurting them the most not their tech debt.