Let's Shelf "Technical Debt" and talk about "Design Debt"

As the Agile philosophy picked up steam (and started generating consulting profits), us developers were introduced to the concept of "Technical Debt."

Technical Debt was intended as a way to present sub-optimal technical implementations in the business "friendly" concept of financial debt.  The delta between the optimal solution and the sub-optimal solution is the debt you burden yourself with immediately.  This debt gains interest as long as you do not pay it back by implementing the (now possibly different) optimal solution.

While this metaphor is somewhat useful when discussing the impact of a decision with management, since it never reaches the stakeholder report, there's (in my experience) very little traction to fully pay back the debt.  You sometime make a "good faith" payment (interest only?), but you're usually just left with something "less bad."

We need to move past "Technical" Debt.  The impact is just not there, and very few engineers (or managers) will champion the payment of something that "just works as it is."  Paying customers pay for new things, or fixing their problems.

I propose we start teasing out the truth of the debt.  One of these is "Design Debt."  Design Debt is a high stakes debt that will crush your pace, and can make a seasoned engineer cry.

Design Debt is the sub-optimal design decision made because you are using an Agile Methodology: requirements firm up over multiple iterations, so the design decision you made in an earlier cycle (sprint, Epic, etc...) is already sub-optimal.

Take, for example, deciding that you should implement an Entity-Attribute-Value data model since you heard the customer make a high level request for a system that you can "dynamically add fields to." 

If you start moving forward with that (because we're "sprinting"), prior to engaging the customer in a deeper discussion, Congratulations!  You've got "Design Debt".

And 3 years later, after you're finally going to production, and find the system cannot show a significant portion of your data because it times out querying for the data, you now have to allocate a full time senior developers time for, oh, 8 months to completely tear it out and put in a normalized data model.

If you get just one thing from the above, make it that Entity-Attribute-Value is a last resort model!