The software engineering equation

NOTE HXA7241 2010-10-06T20:11Z

Harrison Ainsworth

If there were a single equation summarising all software development and use – a ‘law of infodynamics’ – what would it be like? – Here is a quick imagination of one.

First there is a definition of information from the lecture ‘Information Engineering: Where we have been and where we may be going?’ by Mike Brady at wbcvsn-elaboration:http://www.eng.ox.ac.uk/events/centenary/movies/brady2008.html, at 51m 02s – 52m 03s:

“For any given action, in any state, we can define the utility of that action, state. The information content of an action is the difference it yields in the expected utility of the state after carrying it out.”

That could be written as:

i(a) = u(a(S)) - u(S)

the information of an action, equals: the utility of the state changed by the action, minus the utility of the state

which, with a liberal sense of analogy, is not so far from the physical world's: energy = force . displacement – if you think of information as energy, action as force, and state change as displacement (remember, this is imagination).

This information formula maps straight to software use:

  • state = the data input in running the software
  • action = running the software
  • utility = the usefulness of particular data, either input or output
  • information = the ‘magic ingredient’ in the software running that made the output data more useful than the input data

It also maps straight to software development:

  • state = the software (code etc.) before the development work (which could be nothing, or a previous version)
  • action = software development work (i.e. that done by programmers etc.)
  • utility = the usefulness of a particular software version (according to the users)
  • information = the ‘magic ingredient’ in the development work that made the new version of the software more useful than the previous one

So both software development and software use can be viewed in the same way in terms of information activity. The differences in state and utility are just in perspective or scale: software is itself data, just changing more slowly than other data, and the utility is different in a similar way. The key difference is in the action: in software use it is done by computers, and in software development by humans.

But, as initially stated, this is only fake. The original information definition is pseudo-mathematical: it is saying that something ill-defined is related vaguely to something else ill-defined – which is saying nothing much at all. The elements need independent, objective measures, like (at the very least) function-points for utility, lines of code for work, and some measure of state change. And then, even if that could work, it would still be only the tip of an iceberg.

It still seems interesting or appealing in some way though, despite its hollowness. It conjures up a way of thinking about software engineering that seems clearer and more bounded, more understandable: seeing both human and software work in terms of single unified systems of ‘computational activity’, with defined transforms on defined states of data and information . . .