My third piece on semantic debt is up at
TDAN.
I tried to do three things in this piece, which is probably two too many. First, I wanted to clarify a lot of the points I'd kind of mumbled through in the prior two pieces. That involved some pictures, and some more examples.
Second, I wanted to make sure we were all clear on what "semantics" means. Theories/systems/models are about something in the world, some state of affairs, scenario or situation. The
semantics of that system is the assertion that the system is about some part of the world. In less philosophical terms, the semantics of the system is its
specification documents, or more precisely its technical documentation. And let's be even more precise. A friend of mine who was a technical writer once described what he did as the contract between the user and the company; whatever the marketing people might put in their copy or the sales people might promise, it was what was in the manuals that the company was on the hook for. If the manual said the software could do something and it couldn't, or
vice versa, then users would have a legal claim on the company for fraud. You should think of the semantics of a system, then, as the contract between the system and the world.
Third, I wanted to talk about how you might pay the debt down. And I wanted to do it in the third piece, even though the two prior points were probably critical before I could do the third. Paying down semantic debt isn't hard, but there's some complexity involved. The reason I started this blog was to start putting some details around the idea. But I wanted to get some structure into the discussion so I could start to work through a logical remediation plan.
Because the problem isn't that semantic debt is invisible. Everyone knows they've got it, even if they don't use that exact term to describe it. The problem is that when enterprise architects or software architects or data architects sit down to figure out what they're going to do for the next year or even quarter, they point to blobs of stuff and say "we need to fix this." There's no analytical framework that helps divide up an enterprise's data management assets into useful pieces to try to decide why and where those assets might fail and thus what needs to be worked on next.
There's obviously a lot more to be said.
