>Technical debt is ok, and often a solid product strategy. The importance is getting to market.
Apparently they're using Rails or PHP at Bigcommerce. If you're trying to get to market as fast as possible then Rails makes sense but what goes with Rails is TDD. You really shouldn't have too much technical debt when you're using Rails or Ruby.
On the other hand, if they're using PHP then I'd bet a lot of money that they have a lot of technical debt because they hired poorly skilled developers who were able to push through some code that looks like the feature requested.
At some point, you will be crushed under the weight of your own technical debt. The race is whether your startup will die before that point. The author sounds like he's trying to get acceptance that there will always be technical debt. How about letting your engineers working on refactoring and making things nicer?
Facebook could have been crushed by their technical debt but instead they let their engineers loose on the code base. That's how they've come up with Hack lang which is type-annotated PHP, and that's how they've come up with flow, the javascript type checker. This is why they made it a mission to allow developers to be able to fix and deploy some code within 1 week of starting a job. All of that forces them to fight against technical debt and to keep themselves in the game.
That's the real issue here; sure it sucks creating technical debt in an effort to get to market first, but it sucks even worse when as an engineer you aren't allow to tackle the debt at any point or are only allowed to tackle it very rarely. Efficiency is what will keep the dollars rolling in.
A recent example involving Google is Chrome. People are actively switching back to Firefox or another browser. There's bloat in Chrome! How's that possible?! My bet is a product manager who isn't allowing the engineers to fight the technical debt in the code.
Apparently they're using Rails or PHP at Bigcommerce. If you're trying to get to market as fast as possible then Rails makes sense but what goes with Rails is TDD. You really shouldn't have too much technical debt when you're using Rails or Ruby.
On the other hand, if they're using PHP then I'd bet a lot of money that they have a lot of technical debt because they hired poorly skilled developers who were able to push through some code that looks like the feature requested.
At some point, you will be crushed under the weight of your own technical debt. The race is whether your startup will die before that point. The author sounds like he's trying to get acceptance that there will always be technical debt. How about letting your engineers working on refactoring and making things nicer?
Facebook could have been crushed by their technical debt but instead they let their engineers loose on the code base. That's how they've come up with Hack lang which is type-annotated PHP, and that's how they've come up with flow, the javascript type checker. This is why they made it a mission to allow developers to be able to fix and deploy some code within 1 week of starting a job. All of that forces them to fight against technical debt and to keep themselves in the game.
That's the real issue here; sure it sucks creating technical debt in an effort to get to market first, but it sucks even worse when as an engineer you aren't allow to tackle the debt at any point or are only allowed to tackle it very rarely. Efficiency is what will keep the dollars rolling in.
A recent example involving Google is Chrome. People are actively switching back to Firefox or another browser. There's bloat in Chrome! How's that possible?! My bet is a product manager who isn't allowing the engineers to fight the technical debt in the code.