Thread by @RonJeffries

We might like to imagine that there's some perfect mix of design quality, code quality, and test quality, to build a perfect product. But that's not the case. There's room for all those elements to mush around:

We can even compensate for imperfect design with additional coding, and for imperfect design and code with testing. (Which is itself imperfect.)

The "technical debt" conundrum is whether we can judiciously use this flexibility to deliver more, sooner.

Now the picture above already begins to show the problem. If we do less work on quality, the features won't be quite so perfect, because design, code, and test quality are part of perfecting a feature. But can't we make it up later?

Well, first of all, later's never coming. Whoever is pushing us for more now isn't going to turn all fairy godmother tomorrow and slack off. We likely won't get the chance to clean it up.

Furthermore, it doesn't work that way anyway. We can't just go back and jam more design, code, and test quality into that old code, even if we had time to do it. It goes like this: not a neat insertion, but a hard messy job.

So, our dreams of judiciously scaling back design, code, and test quality to go fast now, and making it up later ... well, dreams.

Yes, we can go faster now, for a while, by skimping. But we'll probably never make it up. Our product and progress will suffer forever.

Is it possible to skimp now on design, code, and test quality, and go faster for a bit? Maybe. Will we ever pay off the debt? My money and experience say that's a bad bet.

Now go do as you see fit.