‘Software Design’ Is Not Design


Harrison Ainsworth

Software engineering has veered a little off on a tangent. Its priorities have become unbalanced. Or at least the perception has.

What is software design? – modularisation, class relationships, etc. – the structure of the code. This would be the normal view. And also accords with: Swebok 2004, 3-1 p51; and IEEE 610.12-1990.

This is unsound. If you asked a civil/structural engineer about the design of a building, and they talked only about the style of diagrams and presentation of equations used, you would think there was something wrong: What about the resultant forces? the resilience to conditions? . . . what about the actual function of the building – how it stays standing-up and working?

Engineering is about the functionality of what is produced, foremost. What helped the engineer design it is a side issue. The structure of internal representations – the code – has some value, but it is not essential: because it is only to serve the engineering process, it does not constitute the product. As an engineering kind of task, software design is really about storing data, moving data, and processing data. That is the functionality it creates, that is its core.

How valuable is representational structure? At a worst it could have a severe indirect effect: much less product functionality would be developable with available effort. But the opposite is different: products have ‘essential complexity’ that cannot be short-cut by refinement of tools – only re-use can help substantially. Complaints and wishes about languages etc. are figments. They arise because, unlike something physical, software lacks a defined tangibility to show the objective limits of its medium.

Software engineering should devote some attention to the representation structure, but it should not become a self-indulgence.