This strikes home to me. I would summarize as: * Technical debt is a result of a mismatch between technical architecture and business needs (this comes from Wa

This strikes home to me. I would summarize as: * Technical debt is a result of a mismatch between technical architecture and business needs (this comes from Ward Cunningham, the originator of the concept, the OP says) * OP wants to analyze this mismatch in two main categories: 1) The technical architecture was wrong from the start, as a result of not understanding the business requirements (domain) accurately enough. He calls this "wrong design". (While the OP doesn't say so, I think you could further subdivide this -- you thought you understood the domain but had some misunderstandings; or you knew you didn't understand the domain sufficiently, but had to or chose to proceed anyway to be good enough for now). 2) Originally there was a good match between technical architcture (design) and business requirements (domain), but the environment changed, you have new requirements/demands that didn't even exist in original implementation. He calls this 'rapid evolution'. In fact, I think those categories can overlap -- the landscape always changes, part of good design is attempting to predict some of that change. This is the trick with software design in general, you are always trying to plan for future needs, and trying to predict the future is always inexact. Still, these categories seem useful to me conceptually anyway, even if not an exact bifurcation. Some technical debt (design problems) seem more like one or the other. OP says for the first category "bad design", you reduce it by spending more time understanding the requirements/domain. For the second category, "rapid evolution", you write code that is easier to refactor. Ah, sez me, but there is the rub, that's exactly what's hard, writing code taht's easy to rrefactor! Especially because it requires predicting the future itself, everything is easy to refactor on some dimensions more than others, requires trying to predict the tthings likely to be invariant vs the things likely to change. Still, I think these are some good guidelines, it's not really one or the other, think about how much you can invest in both these paths -- understanding your domain better (which really means what kinds of changes are likely in the future), and making code easier to change, even in ways you didn't predict.