I see a lot of wisdom in this article and I find myself nodding, but I'm dubious whether it's effectively communicated from the article per se or its just my experience dovetailing with the author's. The problem is that "technical debt" is an analogy, and like all analogies, it breaks down. It's never a choice between writing perfect code or hacking together the fastest ugliest thing that could possibly work, rather all long-term software development is a continuous series of tradeoffs heavily dependent on an unknowable future.
Consider the center-point of this article:
> I view technical debt as any code that decreases agility as the project matures.
Well, any given piece of code can have positive or negative value based on what change you need to make in the future. You can have a perfectly factored, elegant piece of code which becomes useless if the job to be done changes, at which point you are better with no code than the previously ideal code. On the other hand, you can have a module which is ugly as sin, unreadable, and horrible in every way, but it does a job that never needs changing, and it's isolated enough that no one ever even has to look at it or consider it.
So the very judgement of the scope and severity of technical debt depends non-trivially on the future. Individually design decisions can be critiqued, and the likelihood of certain types of changes can be weighed out, and certainly the best engineering and product teams are very very good at this, but the fact is that the whole endeavor is terribly fraught and difficult to concretize.
All that said, I think the author is absolutely right that engineers often have a proclivity to polish some bit of code or architecture when their time would be better spent elsewhere, but it's just a tiny microcosm of the problem facing all startups: you need to build a money-making machine, and you have infinitely many dials to turn, with only a handful of (hopefully) smart people on a very limited runway. How do you make decisions day-to-day about where your greatest marginal utility lies? I don't think there are any rules of thumb that are globally applicable. If you are lost, a blog article is not going to help you. The only hope is to gather feedback as widely and quickly as possible and be brutally honest with yourself.
Consider the center-point of this article:
> I view technical debt as any code that decreases agility as the project matures.
Well, any given piece of code can have positive or negative value based on what change you need to make in the future. You can have a perfectly factored, elegant piece of code which becomes useless if the job to be done changes, at which point you are better with no code than the previously ideal code. On the other hand, you can have a module which is ugly as sin, unreadable, and horrible in every way, but it does a job that never needs changing, and it's isolated enough that no one ever even has to look at it or consider it.
So the very judgement of the scope and severity of technical debt depends non-trivially on the future. Individually design decisions can be critiqued, and the likelihood of certain types of changes can be weighed out, and certainly the best engineering and product teams are very very good at this, but the fact is that the whole endeavor is terribly fraught and difficult to concretize.
All that said, I think the author is absolutely right that engineers often have a proclivity to polish some bit of code or architecture when their time would be better spent elsewhere, but it's just a tiny microcosm of the problem facing all startups: you need to build a money-making machine, and you have infinitely many dials to turn, with only a handful of (hopefully) smart people on a very limited runway. How do you make decisions day-to-day about where your greatest marginal utility lies? I don't think there are any rules of thumb that are globally applicable. If you are lost, a blog article is not going to help you. The only hope is to gather feedback as widely and quickly as possible and be brutally honest with yourself.