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.
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.
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.
Comments
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.
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.
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:
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.
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.