My biggest gripe is the lack of respect/understanding for the importance of data models and clear domain boundaries.
Most things that end up as “technical debt” can be traced to this. Sometimes, it’s unavoidable, because what the data models changes, or the requirements of the domain, etc.
And, it’s very innocent looking differences sometimes. Like “We know that the external system state will change from A to B, so we can update that value on our side to B”. Suddenly you have an implicit dependency that you don’t express as such.
Or, things like having enum that represents some kind of concept that isn’t mutually exclusive. Consider enum values of A and B. Turns out this really represented AZ, and BP (for some inherent dependency to concepts Z and P). Someone later on extends this to include ZQ. And now, suddenly the concept of Z, is present in both AZ and ZQ, and some consumer that switches on concept Z, needs to handle the edge case of AZ… And we call this “technical debt”.
My biggest gripe is the lack of respect/understanding for the importance of data models and clear domain boundaries.
Most things that end up as “technical debt” can be traced to this. Sometimes, it’s unavoidable, because what the data models changes, or the requirements of the domain, etc.
And, it’s very innocent looking differences sometimes. Like “We know that the external system state will change from A to B, so we can update that value on our side to B”. Suddenly you have an implicit dependency that you don’t express as such.
Or, things like having enum that represents some kind of concept that isn’t mutually exclusive. Consider enum values of A and B. Turns out this really represented AZ, and BP (for some inherent dependency to concepts Z and P). Someone later on extends this to include ZQ. And now, suddenly the concept of Z, is present in both AZ and ZQ, and some consumer that switches on concept Z, needs to handle the edge case of AZ… And we call this “technical debt”.