All too often technical IT people have two tendencies:
- “Let’s make an abstraction of it” (be it a frameworks, tooling or patterns) also known as another level of indirection (See David Wheeler‘s famous indirection aphorism) (in Heideggerian terms: “the hammer becomes transparent while pounding the nail”)
- I have this great hammer to pound down that nail (aka Maslow’s hammer) (kind of like the “the Einstellung effect” in Gestalt psychology)
In both cases one could argue that these technical IT people try to negate/neutralize a problem. In the former case one negates the possible edge-cases, cases that were unforeseen thus rendering the abstraction leaky. In the latter case one negates their own incompetence i.e. not pragmatically using tools what they were designed for due to a person’s predisposition to solve a given problem in a specific manner. In both cases one does not see possibilities negative and positive respectively.
- Some IT examples of leaky abstractions and their return-of-the-repressed are in order here:
SQL abstracts away the procedural steps needed to query a DB but when queries are slow we have to grok the explain plans
- On a higher level of abstraction Hibernate is even more leaky since it allows developers to use OOP principals to query the relational database with more ugly/slow queries as a result
- SOAP Specifications like WS-ReliableMessaging abstract away the mechanics of delivering messages only-once and in order but shouldn’t that be a business concern? The history of computing fads is littered with failed attempts to abstract functional requirements in protocols
- A more extreme case is TCP which takes care of reliable data transfer but when one physically cuts the cable all breaks down
In all cases one strives for a simplification of something much more complicated that is going on under the covers which is a pretty smart thing to do. But as reality imposes a close to infinite possibilities/occurrences one can also note that all non-trivial abstractions, to some degree, are leaky. Coupled with Murphy’s Law and the fact that there are black swans out there one should not underestimate the possible time-sinks these abstractions sometimes introduce. In the case of Heideggers transparent hammer the transparency would brake down once the nail that is to be pounded is positioned in an awkward place like a corner. A special kind of hammer is needed in this case. Otherwise the carpenter will do weird movements and lose time with his all-purpose hammer.
Nonetheless all too often those abstractions/frameworks/tooling are leaky, meaning that those complexities you are trying to get rid of start popping up again. The problem appears again but with a twist and in IT it often requires a solution that is more convoluted than when one would not have abstracted. A bit like in psycho-analysis where the behaviour of the patient becomes twisted and contorted when the repressed tries to return. In the end one could say that an abstraction is only non-leaky in its application. What is meant by this is that negation only works when the repressed does not occur. This repressing/abstracting is dragging IT down. It’s the yin to the abstracting yang force. It’s also a fact that the repressed is often times not well understood by the technical IT person since living in abstraction-land has made him ignorant of the underlying complexity.
Of course one could not argue against the use of abstractions since it’s one of the positive driving forces in IT. But rather I’m arguing to apply those abstractions carefully and flexibly. Foresight does not exist but it helps to know what the abstraction you’re applying is repressing when used. My plead is in a way to use more psychoanalysis in IT.