The second basic question of software engineering

NOTE HXA7241 2011-06-12T08:55Z

Saying we want to improve how software engineering is done seems OK, but can that be clarified? We understand what kinds of computation are efficient by formalising the idea of what computation is. We can perhaps understand what development is efficient by formalising what development is.

The first basic question

“The fundamental question underlying all of computing is: What can be (efficiently) automated?”

‘Computer Science, The Discipline’; Denning; 1999.

This is the real core of software engineering: how much time and space (and perhaps energy) does a computation take? and will it fit the intended/expected computational resources? The most indispensible requirement of any project is that, within real constraints, the thing will actually work.

The second basic question

But there is a second basic question for software engineering: how much time and resources does development take? – or, ‘What can be (efficiently) developed?’.

This follows from what could be distilled into the two underlying goals of engineering generally (see ‘Understanding Software Engineering Design’): the first is to maximise requirements fulfilment in the product, and the second is to minimise the development effort to do so. We want the project to work and be correct, but we also want it done at reasonable cost.

The second question is not so important, and also more difficult. It cannot, it seems, ever be answered so definitely: engineering work is creative and indeterminate; we never know exactly what is wanted, nor exactly how to do it. But despite this, it is something we would like to answer somehow. (How much can it be answered? and how precisely?)


“we construct our mechanical symbol manipulators by means of human symbol manipulation”

“computing science is concerned with the interplay between mechanized and human symbol manipulation”

‘On the cruelty of really teaching computing science’; EWD-1036; Dijkstra; 1988.

The second question will be answerable in terms of the technical forms that the projects are representable in. Answering the first question is done in terms of sorting, searching, etc. – general algorithmic forms – which problems fit which algorithms. So answering the second question will be similar: which projects fit which developmental forms.

This is what formalisation means here: looking from the perspective of the technical medium: seeing the vague behaviour through the discrete, objective parts it is expressed in. Though development seems vague, complex, ungraspable, it is done through a medium that is well-defined and simpler – and that is what can be understood. How we solve problems is obscure, but the manipulations that the medium can undergo are determinate, clear, precise.

Answering the second question is about clarifying what kinds of software modification are possible, and what properties, including costs, they have. This is the proper basis. There is otherwise a vague, implicit, goal of making software development easier, but this cannot in general be quite right. As Brooks noted, there are essential costs to development, that cannot be significantly avoided. Simply making things better is an uninformed goal: we need to know the terrain before we can see where we can go.

Concretely, specifically, what does this mean? For computational efficiency we have analysis of algorithms – addressing the ‘functional’ aspect of software; for development efficiency we want something like ‘analysis of abstractions’ – addressing the ‘representational’ aspect of software. But what would that be exactly? . . .