Conceptual debt occurs when an organization makes bad design choices from adopted models that don’t align with the business and customer needs. This kind of debt is not easily recognized and is prevalent in most teams lacking a solid digital strategy. While technical debt gets all the press, conceptual debt is the undetected metaphorical hammer that is coming for digital places (software, app, intranet, etc).
Let’s consider the difference between technical and conceptual debt. Technical debt is unsound software practices implemented to solve short term problems (things like speed and functionality) at the cost of quality code. The process of solving technical debt is usually achieved through the technique of refactoring — reviewing and improving a product’s code. It’s considered a pretty common practice to refactor code when it is no longer easy to maintain or change.
But in recent years, a growing group of system architects and product managers argue that technical debt is often confused with conceptual debt. Conceptual debt becomes the consequence of developers trying to make sense of requirements that reflect complexity in their organization. (We’ve talked about complexity before; it can exist pretty much anywhere where people are trying to solve hard problems). While the cause of technical debt is poor coding, the cause of conceptual debt is the accumulation of poor understanding—at a practical level, poor models that don’t properly match the objectives of the business or organization. Put another way, even essential complexity needs to be understood properly in order to build systems that support it.
Conceptual debt can help to explain reoccurring technical debt. A poorly understood need creates poorly understood code, even if the coders are the best in the world, so it’s important to really understand which problem is actually happening. Not fixing the poor understanding of a problem — the conceptual debt — means the problem will never really go away.
“A rewrite will end up with the same problems as the original unless you close the understanding gap. ”
Conceptual Debt Checklist
It’s very hard to tell the difference between code that is written badly and code that is written to make sense of badly modeled business needs. But there are a few high-level checks listed below that you can make in your organization to confirm this.
And what do you do if your organization’s problem is conceptual debt? In follow-up posts we’ll speak more on the major ways that conceptual debt happens and what your organization can do about it. For now, consider these questions:
☐ Does your team use and refer to models that are not directly linked to implementation considerations? (examples of this are personas, jobs to be done, wireframes, and user journeys)
☐ When someone new is onboarded, is there a common set of models that they all use to get up to speed for the foundational concepts, regardless of which role they will ultimately play?
☐ Do you have regular ceremonies or processes for identifying alignment across your team regarding what models mean, and do you have ways to adjust those models to reflect that alignment?
If you answered “no” to one or more of these questions, you may have a problem with conceptual debt.
At TUG, we are called in to help companies deal with conceptual debt all the time! If you think you might be having problems with it, drop us a line.