“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.

Systems Thinking

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.

When I presented this analogy to the team, it led to a very useful discussion about testing. The test and integration guys came to realise that they could test each guitar pedal on its own based on the specification of its interface and a definition of its function. Further, they could test the composition of multiple pedals in a similar way. The architecture guys came to realise that their job was to specify the interface to and define the function of each pedal based on requirements, etc. But when I added a little more abstraction and came up with a software model describing a pedal interface, I began to lose people. One of the test team put his hand up and asked, “But where is the footswitch in your model? Where are the knobs?”. When I began to probe the team’s understanding of the concepts I’d presented, I found that many of them understood the guitar pedal analogy but could not fully make the link with software architecture and design.
Elements of Digital Transformation
Guitar pedal software interface model

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

February 1st, 2023|

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

November 7th, 2022|

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

April 7th, 2022|

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.