There was a problem, and the microfeature that I was supposed to have done sometime last week turned out not to be working. So I investigated, and (re)figured out that the intended functionality was that message would be received at a particular class, but that method was polymorphically overridden by another method in a subclass, which delegated to a different method on the same class, which was polymorphically overridden by a subclass, which delegated to an interface, which had a default implementation that did nothing, and two subclasses below the interface the method that looked ALMOST like it was overriding the default implementation wasn't ACTUALLY overriding it, so (understandably) the signal was not emitted and the slot was not called and the slot did not delegate to the widget that, had it been notified, would have actually done what it was supposed to do.
Perhaps programmers ought learn a language that has INTERCAL's
COMEFROM instruction, soley in order to understand how misuse of inheritance can be a bad thing.
If this reminds you of
Heath Robinson and/or Rube Goldberg, you are correct. What is perhaps sad is that ridiculous layering and indirection and redundancy is actually how most software works - so far as I can tell, not having examined all software everywhere - admittedly, this is because to get almost anything done, a causal chain needs to traverse a huge number of ossified organizational barriers. The widget library, application, networking library, kernel, and service are probably all written by separate organizations, and it is only by looking at a particular transverse chain of events (as you might if you were debugging) that you can perceive the ridiculousness that is happening EVERY SECOND.
However, even within one fairly small team, accidental complexity can cause those ossified barriers and ridiculous chains, if it is not assiduously cleaned up. Sigh.