Design Debt

A specific type of TechnicalDebt. DesignDebt accumulates as you write code. It is reduced when you refactor. The debt metaphor comes from WardCunningham -- see ComplexityAsDebt.

Do different activities cause DesignDebt to accumulate more quickly? For example, does implementing an up-front design result in less DesignDebt than writing code without explicitely designing it first? Does adding a feature to an existing codebase cause more DesignDebt than writing new code from scratch? Does code that is simple but specific have less DesignDebt than code that is more complex, but generalized and specifically extensible?

Up-front design

You assume a degree of DesignDebt, and eliminate that debt by performing explicit design. You then accumulate debt as a function of how much your design differs from what is required in practice, and the number of small details that the higher-level design does not cover, but refactoring would catch. Thus, the value of up-front design is limited by how ambitious the design is, and how much time elapses between a design and its implementation

If you code without an up-front design, you accumulate DesignDebt more quickly, and will require more refactoring to remove it. ExtremeProgramming for example, does its up-front design in CRC sessions before each programming task, so that the scope of the design is limited to the task at hand, and no DesignDebt will be incurred by making incorrect assumptions about future tasks. It then relies on RefactorMercilessly to eliminate the debt incurred by not having more detailed or far-reaching designs.

Adding features vs writing from scratch

In a well-factored system, the cost of adding a new feature should place you in less debt than writing the same code from scratch, depending on how much of the existing system you are able to reuse, or refactor to allow the feature to be added. Even if there is no chance to reuse code, the patterns of the existing system can be reused to reduce the number of design decisions you have to make.

Of course, DesignDebt will increase if you do not refactor, until the cost of adding new features is greater than it would be to code them from scratch, as you not only have to design the feature you are adding, but also design your way around the flaws in the system you are attaching it to.

see the DesignDebtDynamics diagram of effects.

Very nice. But isn't there an additional kind of DesignDebt due to implementing parts of the design before they are needed, resulting in a corpus of code that is (a) larger than it needs to be, and (b) leaning in a potentially wrong direction? The part of DesignDebt that pushes towards YouArentGonnaNeedIt?

This would be analagous to getting an investment loan, then sitting on the money for six months (paying interest) before investing the money (and potentially getting rewards). Borrowing more money than you need is a bad investment strategy. Writing more code than you need would also seem to be a bad idea.

I don't think the analogy stretches quite that far. The thing about money is that if you don't use it for one thing, you can use it for something else. A better analogy could be inventory management - the more of your inventory you stock up-front, the more likely you are to buy things that you are never going to need, and run into problems when you haven't bought enough of what you do need. On the other hand, running a flexible, just-in-time inventory takes a lot more organisation and attention to detail from day to day.

Perhaps this is more analogous to excess baggage than design debt. Design debt is where we aren't paying as we go, and end up having to pay extra costs, interest, for doing it later. Excess baggage is where we do something we don't need to, and end up paying extra costs for carrying it along (kind of like needing more fuel and/or reducing the range of a plane loaded with excess baggage). Moving in the wrong direction is more like taking a wrong turn where we have to pay costs (take time) to back track to the crossroads and take the right turn, or cut across the woods to get over to the right road. All three of these end up costing valuable time and resources, so if the preventative measures (e.g., YagNi, DoTheSimplestThingThatCouldPossiblyWork, Refactoring) cost less than the average cost of the recovery (plus missed opportunity time, etc.), then it's better to prevent them from happening in the first place. --PaulHodgetts

See UpfrontDesignIncome