The Way We Look at Technical Debt Is Wrong

Ergo, in your scenario even with 10 users, the application basically died under its own weight under nominal use.

And I accept that there are times when you can move faster by accepting technical debt.

However, I'm always uncomfortable when this view is preached, because I think that while all these things are true, they are rare. The most common case is that when corners are cut, or 'tactical' solutions are adopted, you begin paying for them within a week, often before you've even finished implementing them. Another common case is that doing something in a way that allows future change is almost no extra effort compared to taking on the technical debt, but the vision or mental effort (or political will....) isn't there to even try to see things in a new way.

So sure, sometimes we should embrace technical debt wholeheartedly, but most people are already too far in that direction already. I'd rather read articles about people who spent a little extra time thinking in these situations and came up with a solution that was quicker to implement than the original plan, with less, simpler code and fewer bugs. I think such things happen just as often as technical debt producing good outcomes.

Even worse, if you're then not equally technical as a manager you will never know whether you've made a solid choice by aligning with or against the engineer's view, and even worse your engineers will quickly take on a "see, I told you so" stance should things work out not perfectly under an agile model.

Edit: I should add that I am an engineer myself.

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.