Ask software architects, tech leads and developers what skills are valuable in developing software systems, and inevitably someone will say 'abstraction'. Ask how a system should be structured, and inevitably someone will say 'levels of abstraction'. Look at programming or modelling paradigms and — inevitably — 'abstract' will appear, as a noun, verb, adjective or keyword. Being so steeped in the terminology of abstractness and abstraction, you would be forgiven for thinking that software developers would have a clear and ready definition of what abstraction means. You would be forgiven, because you would be wrong.

Although a foundation of much of computing and progress, developers have varied views on what it means for something to be abstract, often confusing 'abstraction' with 'generalisation', or being unclear about the relationship between 'abstractness' and 'level', or equating 'being abstract' with 'being vague'.

In this talk we will look at what 'abstraction' means in theory and in practice. We will see how knowing this helps us to understand the relationship between abstraction and progress in software development in the past as well as its future. It also helps us to properly evaluate claims about AI and abstraction from the perspective of both developer and user.