“How can the concept of abstraction in software engineering be so difficult to understand and apply?”
I’ve been supporting a software development team that is working hard at bringing their engineering practices into the 21st century. Their challenge is to develop next-generation, highly complex software. To this end, I’m introducing them to some fairly standard software engineering concepts such as abstraction, decomposition, compositionality, components and interfaces, etc. Some members of the team are taking on these concepts, like ducks to water. But for many, the penny hasn’t yet dropped.
As a simple introduction to the basic ideas, I used the analogy of a guitar foot pedal – of which I happen to have a couple sitting next to my desk. A guitar foot pedal has configuration parameters (the knobs on the pedal), state behaviour (on/off function), input data (signal from the previous stage), output data (processed signal) and error reporting (fault LED). The nice thing about the guitar pedal analogy is that, in principle, at least, pedals have a common interface and that they are usually composed together in series, the output of one pedal being plugged into the input of the next.
Thus, we have a simple example of a compositional system. Further, with a little abstraction added, the pedals are considered to have a common interface (input, output, configuration, on/off, error), and one can explain that the interface to a component is decoupled from its function — in other words, polymorphism in action. E.g., two pedals with the same interface can perform different signal transformations, e.g. reverb, delay, fuzz, etc.
For these guys, “abstraction” is another word for vagueness and “decomposition” is something that happens on an episode of CSI. For some, vagueness is a necessary comfort blanket that allows them to postpone thinking about tricky issues until they are someone else’s problem, e.g. the programmer’s. For others, abstraction is an anathema, and they want to see immediately how, for instance, the foot pedal switch connects to the software on/off function. The consequence is confusion and misunderstanding about precisely what amount of detail is appropriate at each level of decomposition of a software system. Establishing clarity on the subject is necessary if the team is going to successfully engineer complex software.
In my view, abstraction is about defining an appropriate level of detail at every level of decomposition by using encapsulation and fully specified interfaces. Or, to quote a great man, at every level of decomposition, “Everything should be made as simple as possible, but not simpler”. This is not that difficult to understand, is it?
Read more
An outbreak of hubris
Software is the medium of digitalisation. If you don’t understand software, you have no hope of coming up with a decent digitalisation strategy.
Software is not a component of a vehicle
Automotive OEMs have evolved to become highly efficient outsourcing and system integration organizations. Everything related to a vehicle is thought of as a component, including software. The whole automotive system engineering process treats software as a component of a vehicle. This prevents them thinking about the software as a whole system.
Abstraction versus Vagueness in Software Engineering
Some software engineering teams have a problem understanding the difference between abstraction and vagueness. Since one is essential to the architecture and design of complex systems and the other leads to technical debt and poor software quality, software teams must grok the difference.