Abstraction versus vagueness

How can the concept of abstraction in software engineering be so difficult to understand and apply? I’m currently supporting a software development team 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, including abstraction, decomposition, compositionality, components and interfaces. 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 behavior (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’re 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 can be 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 – two pedals with the same interface can perform different signal transformations, eg reverb, delay or fuzz.