The Dangers of Abstraction
Abstraction is a powerful thing. It enables us to compose ever more elaborate ideas, as dwarves standing on the shoulders of giants, and it is what has enabled us to build the immense edifices of religion, philosophy, economics, technology and science.
Highly abstract concepts depend on other concepts which in turn depend on others and so it goes on. Turtles all the way downIt’s interesting to compare concepts with features extracted by deep learning algorithms. These algorithms are often criticised as being opaque but how many of us really know why we think what we think? .
In the modern age where complex ideas are stated in tweets, of which we receive hundreds per day, they can easily can loose their grounding and their original meaning. This opens the door to misinterpretation.
As software engineers we are as prone this as anyone, maybe more. We talk endlessly, and it must be said sometimes carelessly, about components and agile and quality and architecture and a whole raft of other conceptsand right and wrong and justice and value and religion and love and … . We go around in circles debating what these things actually mean and end up, in the best cases, agreeing that it depends on context, whatever that means, and in the worst cases we end up sticking to our ideas like glue and conclude by telling ourselves that other people are just stupid.
Mostly we assume that words will be interpreted by other people in the same way as we interpret them. Many times they don’t and, what’s worse, we usually don’t even know if they have or not. I once overheard an entire conversationThe joy of open plan offices. where the word “shadowing” was being used by each person with the opposite meaning, one to refer to the act of being shadowed and other to the act of doing the shadowing. It was a bit like listening to a Two Ronnies sketch.
There can be more serious consequences. I know of a project that wasted thousands when a contractor was hired by a technical manager to build a continuous deployment environment. What the manager wanted was continuous*continual* would have been a much better word in this context but hey-ho integration with automated deployment, evidenced by the fact that they didn’t have a single automated test. However he had heard about CD (acronyms for enhanced confusion) and it sounded like just what he wanted. The contractor built what the manager asked for. Politics, saving-face and the sunk cost fallacy dictated that the project went ahead with serious consequences for the development teams.
The continual process of debate and misunderstanding folds back into an evolving language. Consider the word RESTI agree with my colleague Jorge Gueorguiev Garcia that “REST is an architectural style defined to solve Network distributed hypermedia systems. Without Hypermedia there is no REST. If your API doesn’t work through the use of hypermedia, you don’t have a REST API. Maybe you don’t need hypermedia to solve your problems. But then use the correct term.” , familiar to us in software engineering. When this term was coined it had a very definite meaning however it has evolved over the years and now has such a broad range of uses that it has lost a lot of its value. We need so called maturity models just to understand which type of REST we are talking about!
As teachers and mentors, not only must we be careful about how we communicate, we must also take extra care to understand that misinterpretations will happen, in fact there are often multiple alternative interpretations of the same word in circulation. I remember being baffled by a conversation with a colleague about “integration testing”. What he was saying seemed to make no sense. I knew he wasn’t an idiot so I really really tried to understand and apply his ideas. I later found out he was talking about a different kind of integration testingAs so often, Martin Fowler was ahead of us: “And there is a large population of software developers for whom “integration test” only means “broad integration tests”, leading to plenty of confusion when they run into people who use the narrow approach.” . Basically we were talking about two separate things. If either of us had known how these words could be misinterpreted then that conversation would have been a lot shorter.
An that’s the message I want to transmit. The ideas flying around the media are ever more complex and numerous, our communication is ever more frequent and short. There will always be alternative interpretations. It is no longer acceptable to restrict ourselves to our own definitions. We must endeavour to simultaneously understand different alternative perspectives of agile, REST, DevOps, and all the rest of it, to have a full picture of the current software engineering field.