No you're very wrong.
>No, one kind of technical debt arises that way. Not the only kind. There's another kind that arises when everything is in such small pieces that nobody can tell how the pieces relate to each other. You can easily understand each piece, but you have to go through a chain of a bazillion function calls to see what's actually going on.
All this logic must exist regardless of whether it's coupled or uncoupled. You do not alleviate the logical burden by coupling logic together or uncoupling the logic. If you call this "technical debt" then you cannot get rid of it. Why even call it debt then as logic is intrinsic to application.
In fact decoupling logic can improve readability as it marks each piece of logic with a contextual function name. Either way you do not alleviate complexity by coupling logic. You alleviate this complexity problem by providing logical layers, using namespaces, and using good function naming.
Coupling logic into Objects does nothing objectively as it does not eliminate complexity it only makes sure that the complexity is LESS modular.
Let's be clear though. I am saying that the lower levels of your application should be ALL uncoupled logic. Then you build logical layers on top of your primitives that consists of compositions of your logic that build higher and higher. So a person on layer 5 only needs to go to layer 4 to understand it, and does not need to go to layer 1 to understand every primitive.
>This is like economists, who have correctly predicted nine of the last two recessions. Sure, you're prepared for when the change comes (if you can find where to make it - see above). You've also prepared for all the changes that never come. That's rather wasteful.
Analogies don't offer proof of an argument. Additionally it's not a good analogy. Economists don't completely understand what causes recessions and how to prevent them. We do, however, completely understand the difference between uncoupled logic and coupled logic.
>Sure, it may. And when that happens, we'll decouple it. And in the meantime, we'll enjoy the coupling that, at the moment, is the correct thing.
This is the main point of tech debt. It is hard to decouple. You can have all logic decoupled at the lowest layer and still have everything be readable. I think the previous sentence is just a type of programming you haven't dealt with. You've never wrote a program with decoupled logic that was readable. Think deeper. There is no reason why coupled logic should be more readable then decoupled logic. The Logic still exists either way, you either compose two modules and give it a name or you don't even use modules shove all your logic into a module with a single name.
>See, this is all in the context of SOLID, the very first piece of which is "Single Responsibility". We don't couple things on a whim.
The problem is OOP does this all the time. It couples state with logic. These two things should be uncoupled.