For large interwoven software systems this complexity seen in the form of service layers, directory services, distributed quorums, etc. is often necessary to achieve availability guarantees. I think that the problem is that engineers are over eager to design these sorts of things and implement them before they're actually necessary. And they do it badly and make life shitty in the process because they still don't fully understand the requirements for such a system. OOP just happens to be the language feature they use to make a mess. It would still be no fun even if they used a straight procedural language like C.
Adding on to this, there's an important distinction described by Parnas back in the 1970s as
> Software can be considered "general" if it can be used, without change, in a variety of situations. Software can be considered "flexible", if it is easily changed to be used in a variety of situations.
We frequently forget that these are both valid paths to the same end. We tend to laser-focus in on generality, at the expense of flexibility.
And for small problems like the one described, it is usually much easier to go for flexibility at the expense of generality. And I think we should.
