October 2, 2016

The Abstract is 'an Enemy' (With a nod to LibAPI)

  —What's in a name? Everything.

I discovered The Abstract is ‘an Enemy’: Alternative Perspectives to Computational Thinking in the references to Robert Atkey's talk on Generalising Abstraction.

The Abstract is 'an Enemy' is an argument against creating generic names for abstractions. The paper begins with a module name 'ProcessData'. I laughed on reading this having encountered a library called 'API' in my own work. The example struck a chord.

The compelling argument in The Abstract is 'an Enemy' is that software should be designed so that names are specific. The rationale for the specific is two-fold: it forces the design to encapsulate a single thought and it aligns what is being defined with something in the real world.

The paper goes to provide examples on how the increase in abstraction in an effort to simplify leads to complexity. In one example they discuss how the concept of a user is generalized to the point with the resulting concept in the implementation embodies two very different users.

The abstraction of user leads to complexity in the system but also diminishes the ability of the software to serve these users. The shared representation of user in the system resulted in the system not supporting the user's way of thinking about the world.

A misfit is a correspondence problem between abstractions in the device, abstractions in the shared representation (the user interface) and abstractions as the user thinks about them. Here, the abstractions in the ‘shared representation’ (the user interfaces ...) don’t match the users’ way of thinking about the world. Such misfits are known to cause usability difficulties.

 The provides a description of the tension between the need to model the real world and the need to limit complexity in an implementation. It's a good walk through how the design process goes awry and offers some insight on how to correct these challenges.

In my experience, I am confounded by the need to create arbitrary abstractions that obscure the real world. In the domain I work, in I am faced with electronic signals and devices that make up the physical interface to the product. In many cases the signal names presented in the schematics are never captured in the software and an abstraction for a physical device (such as a button) are non-existent.

I don't have an answer other than to suggest that the software implementation is very out of touch with reality. The resulting complexity in the product and simple misunderstanding that results is costly.