I enjoyed the article, although I disagreed on some minor points, some of the broad strokes seem solid to me. Very thought provoking.<p>I think it's interesting to contrast the thrust of the article with Ward Cunningham's original definition of technical debt:
<a href="https://www.youtube.com/watch?v=pqeJFYwnkjE" rel="nofollow">https://www.youtube.com/watch?v=pqeJFYwnkjE</a><p>Wards definition is much more about the differences between the current implementation of the software and your understanding of the problem, particularly as your understanding changes over time.<p>He explicitly says that "tehcnical debt" is NOT an excuse to write known-to-be-poor code, which is why I disagree with the //TOBECLEANED approach.<p>This change in perspective shifts the point of view quite a bit. In some ways this problem defines a startup, your biggest problem is that you don't understand your problem. It's somewhat likely that you won't even have the same problem you'll successfully solve later. The first points are salient here, focus your engineering efforts on the things you don't understand yet, and the minimum support it needs to be viable. Shorten your feedback loop as you navigate the things you do not yet understand.<p>In this light, a startup is actively SEEKING technical debt, because it represents gaining understanding about a problem, and exploring that space quickly. This doesn't mean you have to "cut corners" and do things you know to be flawed, but it suggests focusing on small 'forays' into the unknown, gaining understanding quickly, and being willing to throw away your exploration for a new one if it isn't working. Then once you find a problem you start to understand and seems like a viable direction, you have a body of 'technical debt' that is the work you need to do to bring the software to your new growing understanding.<p>It seems like being willing to throw away the exploration if the direction isn't working out is a key advantage of a startup, along with the quick iteration times and lean support for explorations. This is why I dislike the suggestions of writing known-bad code. You're slowing your exploration down, but you aren't gaining understanding of the problem. It's junk debt, not technical debt. You can carefully minimize the supporting infrastructure your exploration requires, and avoid writing extra code, but you can't just slap it together.<p>It's not enough to flail around building as fast as you can, you have to deliberately learn and explore problems and understanding as you go, and evaluate which ones to put more exploration into and which to abandon. To me, this is the core work of a startup that differentiates it from established companies who are executing on a reasonably well understood problem. The (sometimes gradual) transition happens when you stop exploring, and start focusing on clearing the technical debt from your current exploration.<p>Thanks for sharing the article, I enjoyed engaging with these ideas!