An outline map of software development


Harrison Ainsworth

Here is a way of dividing up and placing the parts of software development. Reality is not as clear-cut, but a map is supposed to simplify and clarify. It is a way of organising thought. When trying to understand something about software it is useful to know where it is on the map.

The intention, and principle, is to see software in terms of other fields: so understanding can be supported by recognised, proven knowledge.

Software Development

There are three main sub-disciplines:

Software Product Design

This is about what the software is and does: the external, usable features. The input is some pattern of intellectual activity: of learning, creating, or communicating. This is tailored to fit the user group and to be realised by digital means. It transforms requirements into a structure of usage.

It is mostly made of two established external fields, adapted for software [1]:

Software graphic design
Conveying information visually.
Software industrial design
Enabling manipulation pseudo-mechanically.
Software Engineering

This is about how the software does what it does: the internal, technical implementation. The input is from Software Product Design: effectively, digested requirements. These are implemented by processing data: efficiently, accurately, reliably, securely. It transforms usage into a system of data processing.

It is made of two established common knowledge and work patterns, specialised for software. It does something creative, with something scientific (in an organised way):

Computational science

This is the determinate, scientific, knowledege: theory of computation, algorithmic complexity, and related things. It is objective, quantifiable, logically manipulable and provable – the basis of understanding the ‘material’ of software. This is the crucial feature in software as engineering.

Engineering design

This is the creative activity. Its purpose is to join the requirements to the capacities of the material; its basis is to embody abstract rational structures; its procedure is recursive and iterative; it is assembling by understanding and experiment. Though it is supported by science and organisation, design at its core is a human skill. [2]

This design work has two products, focused on two separate goals (‘getting things right, and getting things done’):

The algorithm (broadly speaking), and its ability to maximise fulfilment of the processing requirements.
The code, and its amenability to manipulation and evolution, so to minimise the effort of engineering work.
Software Architecture

This is the chief role, doing two main things: leading the development of what is done, and overseeing and co-ordinating the various sub-tasks and interests in a project.

It reflects the established discipline of building architecture. The definitive job is forming what to build – doing a higher-level kind of product design. Architecture works to see and define useful new arrangements and expressions of ‘logical structure’ in human behaviour – to crystallise something of an activity into a unified software artefact. [3]

There is also an aspect that, as part of management, works across all the above:

Development process

This is the organisation. Essentially, it is about knowing where you are: that is, knowing what you have done, and what you still have to do. When there are multiple people working on multiple tasks, with various criteria and dependencies, what was basically a to-do list becomes a complex means of organisation – a process.


  1. ‘Magic Ink’; Victor; 2006.
  2. ‘Engineering Design: A Systematic Approach’; 3rd Ed.; Pahl, Beitz, Feldhusen, Grote, Wallace, Blessing; 2007.
  3. American Institute of Architects, and American Institute of Architecture Students, description of architecture