A Building Industry Model for Software Development

Harrison Ainsworth

hxa7241+articles (ατ) googlemail (dοτ) com



This presents a conceptual framework for understanding software development, modelled on the building industry.

Building is enough like software development to be interesting and useful. Examining and emulating a similar, already evolved, field, both imports knowledge and prompts re-examination of what was familiar.

The chosen principal features of the building industry are described briefly and abstractly. Software is then mapped to this, by substitution of the physical aspect, or by relation to other parts. Then some of the more straightforward implications or analyses are derived.

(This article includes updated parts of the author's previous work.)

(3000 words)

software development, software engineering, software architecture, philosophy of engineering
Creative Commons BY-SA 3.0 License








Software work is commonly rejected as engineering. And there are certainly grounds to. But there also seems a lack of alternative conceptualisations – that are as rich and deep and useful for understanding.

Software contains engineering; and things that aren't. The difficulty is that the field has not been clear: When there is confusion of parts that are determinate with parts that cannot be, it can never really promise dependability, nor comfortably allow proper creative freedom.

Software development needs a sophisticated coherent picture that resolves the parts and relates them together. And it needs to describe or fit their more essential characters or potentials, not just their current state of practice.


A ‘model’ for understanding software development, based on established knowledge, can encompass the differences in software. Of course there are still differences, but viewing them in a setting that supports the large similarities helps significantly. The comparison clarifies. And since the model brings the backing of a substantial body of thought and experience, there are various directions for progress.[eric]

The building industry is long established with a substantial body of work. It offers a complete guide for creative and engineering discipline that is well-known and known to work well. And it has a range and depth that should accommodate comparison with all software enterprises and projects: from large company projects, down to one-person jobs.

Adapting what has worked before is the best base for advance. And a clear conception is the best base for organised activity – especially with software, in which clear thinking is the core.

By taking an abstract view and replacing physical material with digital, the building industry's example can be followed quite closely in concept as well as word.


The model produces adjustments to some main definitions of software development. It is descriptive, not prescriptive. It doesn't intend to deny or limit the experience or possibilities of various parts of software work, just to place them more clearly.

A common view of software construction is also confirmed, and fits with these.



‘Software development’ is the overall form of enterprise or endeavour that builds software.

Building is a large and sophisticated form of enterprise, but it has a few quite clear primary parts. At the top, work is separated into, as an idealisation: architecture, engineering, and construction. In practice, these may tend to be merged (for smaller projects) or subdivided (for larger projects). Each is a sub-discipline and sub-sequence and successively dependent on each other, but not sharply defined.

In summary:

  • Building is the overall enterprise.
    • Architecture is advocational: it concerns the external, user-facing, usable features. It is the ‘what’, and serves client wants.[arch]
    • Engineering is technical: it concerns the internal, non-usable features. It is the ‘how’, and implements architecture.[hend]
    • Construction is practical: it concerns actualising the ideas in a usable material. It realises engineering.[hend]

This can apply to software with one main adjustment:

  • ‘Software Development’ – the whole, equivalent to ‘building’.
    • ‘Software Architecture’ – equivalent to building architecture, but for logical not physical structure.
    • ‘Software Engineering’ – equivalent to building engineering, but for the computational not physical medium.
      • ‘Software Construction’ – absorbed into engineering, because there is no equivalent material realisation.

Other parts

The building industry has other necessary parts that also map easily into software. These include management predominantly, and things related to that. Since they are less specific to the medium, they are not dealt with here.


‘Software architecture’ is the reflection and creation of logical structure in human activity, and its expression in various material forms. It is ‘what’ to do.

In building, architecture is the ‘chief’ part, doing two main things: leading the development of what is done, and overseeing and co-ordinating other sub-tasks. It contains engineering, but its important feature is not engineering. The overall guiding purpose cannot be achieved with only logical/determinate knowledge. It oversees management, accounting, etc., but these are not essential to it. The various ‘hows’ are subservient to the ‘what’, and the formation of that ‘what’ is the definitive factor.

Architecture is the imaginative blend of art and science in the design of environments for people.

People need places to eat, work, live and play. Architects transform these needs into concepts and then develop the concepts into building images that can be constructed by others.

– archcareers.org (AIA, AIAS)[arch]

By replacing physical structure with logical structure, software can follow building. This immediately gives architecture in software real meaning: it is then the overall external appearance, usage, and function of the software system – it is the ‘what’ – the usage structure. For id's Quake III Arena[idso], for example, it is the desktop executable ‘packaging’, the first-person 3D interface, the game-play, the network multi-playability, the content modifiability, etc.

This separation and delineation of architecture yields a main improvement: it concentrates more attention on pure ‘product design’. This is something of pivotal value in software, and something distinctly of software. Yet otherwise it is without a sufficiently integrated and prominent identity.

(The software world commonly confuses architecture with engineering; it is usually merely a grandiloquence for high-level engineering design. Giving a special word – ‘architecture’ – to what is really a part of engineering is permanently misleading. It actually denotes a difference in degree, but it suggests a difference in kind. There is always an implication of something more, so definitions and meanings always seem to fall short.[sei])

Logical structure in human behaviour

Software architecture is about articulating logical structure, but what does that mean more exactly?

Mere consciousness confers upon almost everything at least some logical properties. Almost everything can be seen and handled in some way discretely and measurably. This aspect is ubiquitous, although varied: Some things partake only superficially or nebulously, like a feeling (at least it has some name and existence), but others deeply and complexly, like physics.

That logical structure is the underlying realm of software architecture. Its focus is the region between vague and determinate, and its activity is to crystallise something for practical use, by means of software engineering. (The same underlying realm also belongs to software engineering, but its purview is the clear and determinate, and its task is to implement architecture.) Software architecture works to see and define useful new arrangements and expressions of logical structures. For example: the Wiki, the 3D game, music recommending/tracking, public transport ticket services, global navigation satellite systems. All these take elements of behaviour and understanding and shape them into unified software artefacts.

Special relation to building architecture

Building architecture fairly commonly has two aspects: usefulness, and aesthetics. Querying these shows something more of the relation to software architecture.

Software architecture is not truly distinct from building architecture. It is an enlargement of it. Buildings themselves have logical structure, in how they behave, how they are useful. But in software this structure is extended; it is more dynamic, and possibly more complex. Most significantly, on the aesthetic side it can have various embodiments – visual, audio, material, etc. So, rather than being analogous to it, software architecture is building architecture generalised.

Organising the sub-disciplines, and leading the whole

An architect serves in a leadership role to bring together the design and budgetary requirements set by the client, restraints of a site (where the building will be constructed), needs of the building's users, and the limitations of materials into a unique and balanced design solution.

– archcareers.org (AIA, AIAS)[arch]

This duty transfers almost straight to software, so it is not dealt with here.


‘Software engineering’ is the assembling of data and computation by understanding their properties, and using experiment where needed. It is ‘how’ to do it.

Engineering in building, or ‘civil engineering’, fits the familiar definitions, roughly: scientific, logical, determinate knowledge employed practically,[pahl] for making buildings. Being centrally about determinate knowledge implies a two-sided identity:

  • From the outside: engineering should know/say clearly what things it can do, and how to do them. Where ‘clearly’ means precisely, certainly, reliably, in a language useful to its associate-disciplines (architecture and construction, for civil engineering). What can be done (for architecture) is expressed as alternatives, trade-offs, costs, material needs. How to do them (for construction) is expressed as instructions and descriptions.
  • From the inside: engineering must be restricted to an amenable medium – one that can be modelled determinately, and scientifically (like physical material for civil engineering). This means the knowledge can be analysed, synthesised and manipulated logically and mathematically. It is structured and objective. And where particular determinate knowledge falls short, an experimental process is used to incrementally gain more. The previous ‘external’ characteristic rests upon this ‘internal’ one.

These two sides provide two ways to define software engineering following civil engineering: first externally, in opposition to architecture; second internally, by replacing atoms with bits.

By separating architecture as above, software engineering can follow civil engineering. The term ‘engineering’, in software, is strengthened by having a proper ‘architecture’. Indeterminate matters like requirements and usability are distanced or removed. And it shrinks somewhat into a more well-defined logical realm – it is the ‘how’ – the technical structure. Then it treats only what kind of data is moved, where, and what processing is done to it. These are the truly essential concerns of engineering for software. For id's Quake III Arena[idso], for example, it is the image rendering techniques, the content data-structures, the network protocols, etc.

This separation and delineation of engineering yields a main improvement: It gives engineering clearer and more regularised requirements, allowing it to work more determinately. Much of the criticism of ‘software engineering’ is deflected, because the uncertainty and vagueness can be seen as having a better defined, separate home in architecture. Any problems don't disappear, but they gain clarity from becoming part of something whose overall shape is known.

Software engineering also follows civil engineering by replacing atoms with bits, but where does that lead more exactly? Software engineering can be divided into four sub-fields: the bit medium, particular subject models, computation mechanics, and representational structure:

Bit medium

Software certainly has a medium amenable to engineering. Comprising purely logical objects, it is necessarily capable of determinate manipulation. But that makes it rather different from a physical medium. Instead of being a material onto which a logical model is projected (so becoming a medium) – like atomic structure – software is its own medium, and its own model.

The constitution of the software medium is very simple and open. The basic elements (bits) have two attributes: an easily changeable property – to be 0 or 1, and a fixed identity – a unique address. The vitality of bits is that they can stand for anything. What particular data is for and how it is used is ultimately pure interpretation. (Computation is merely automated bit-changing according to instructions held in other bits. So it is merely an agent for, and therefore part of, an interpretation.) Software is a medium for general dynamic abstraction, that is: for embodying any logical model of states and transforms.

This is too low-level for direct application. But it would be the basis for theoretical consideration of the forms and relations of abstraction per se – which could help software structure at all levels.

Particular subject models

The freedom and mutability of the bit medium enables software to represent the state and transforms of any model – since a model is just a more sophisticated and structured kind of interpretation. For example, polyhedral objects: the state is made of vectors, and the transitions are by matrix transforms (each made of arrays of numbers). When taken from a mathematical branch, such models are independently well-defined. Otherwise they often must be created to fit an ill-defined source. For example: names and addresses – there are rules, but they are not entirely complete and clear. These are very simple examples, but they extend to things like meteorological simulations, or project management systems.

These various subject models embody logical structures of all kinds and sophistication, from well-defined mathematical, to vaguely defined social. But they are all graspable by software because of their logical aspect.

These models are where architecture and engineering join: choosing and tailoring them is a matter of architecture, building them is engineering. The former is vague and usage-led, the latter is determinate.

Data/computation mechanics

Essential and fundamental to software engineering ought to be quantification and modelling of basic behaviour. That is: the time and space needed for transferring data, transforming data, and storing data. Just as physical engineering calculates resultant behaviour from forces across whole structures, software engineering should capably predict performance of whole systems.[bucc]

Currently anecdotal guides and trial-and-error are prevalent; perhaps because better understanding is not so often useful, given the power of computers relative to everyday tasks. Although some informality is ok, a foundation is appropriate, and engineering strives to replace ad hoc experiment with determinate modelling. Also, reliably predicting extremes/bad-cases (or being assured of their absence) would be quite widely valuable.

This is really the core of software engineering: it is all determinate, purely ‘software’, and only about functionality. (‘Mechanics’ is a reasonable name: analogously from civil engineering, linguistically from Greek for machine.)

Representational structure

Here, there is an important difference from civil engineering. Due to the ease of change allowed by its medium, the software development process is much more iterative – most obviously as a series of versions. This effectively adds another set of requirements: for internal rework. And so a significant extra emphasis has emerged in software.

The representation – the code – is what must meet this extra requirement: to be more understandable and changeable. Because this is distinctive and novel to software, it rightly has special attention. But it is not all of software. The term ‘design’ is casually taken to mean only representation, which overplays its true status.

This is of value but inessential, because it is only to assist the engineering process, rather than constitute the product.


‘Software construction’ is the detailed end of software engineering, from a process viewpoint.

The term ‘Construction’ in software is problematic. In building it is the realisation of a descriptional model into material form. But in software both the model and the product are held in the same digital form. So there is no realisation, so no construction. It would be misleading to use the term in software. Maybe a vestigial form of construction could be seen in wiring-up networks, plugging-in and setting-up hardware. But it does not seem appropriate (or significant) enough to take the name.

On the other hand: from a process/management view, physical ‘construction’ and software ‘coding’ do match quite well. Coding is the detailed end of software engineering design, and building construction also does detailed design. Both bear the majority of time, labour, and risk. So adapting the ‘construction’ term to software could be useful. Furthermore, in building, the stricter separation of construction is a significant source of trouble and inefficiency, so a non-separate ‘construction’ may even be an improvement.[hend2] But it must always be appreciated that this is an artefact of process and management. For software, there is an essential unity of engineering and construction.


There is no ‘maintenance’ in software; it is really development iteration, after delivery. There is no spontaneous/externally-caused degeneration; what changes is entirely deliberate (or should be). It is not different, in activity or purpose, to iteration during the main part of the project. Building probably modifies parts after delivery sometimes, but what do they call it? ‘Renovation’ is not quite right. If there is a distinct name, it perhaps should be adopted by software.


Related Work

‘Prospects For An Engineering Discipline Of Software’[shaw] examines the evolution of other engineerings (civil and chemical). This shows software as immature but with potential. Finally it draws a set of recommendations for software engineering.

‘Is Software Engineering Engineering’[denn] looks at six practices of wider engineering where software is weak.

Those articles have a perspective of comparing practice – what is done or not done in engineering and software. They look at particular features in more detail, and suggest particular actions for software development to adopt.

This article is complementary. It looks more at what software development is. It takes a slightly larger context, and maps other engineering to software more as a whole. And it suggests particular thought – as a prerequisite to different action.


Software is not quite like anything else. But with analysis, and with guiding models, it can be better understood. Software itself does not change. But the structure of the thinking about it, its main properties and relations, can be enriched.

This is rather like refactoring, but with thought–subject instead of code–function: First, thoughts can fit the properties of the subject better; Second, thoughts can fit each other, and external thoughts better. What were vague familiarities and similarities then become concretely exploitable.

Of course, this is not the only possible refactoring. Further and other refactorings, and other work, would be good too. More analysis of architecture, and relating it to the building model. . . More investigation of engineering's sub-parts (especially more mechanics). . . Much more attention to the management side: of the whole, architecture, and engineering. . . And overall, this treatment is essentially static, and examining software development as dynamic, as a process, would be a reasonable next step.


  • [eric] ‘The Cambridge Handbook Of Expertise And Expert Performance’; Ericsson, et al; 2006. – ch. 4, p. 50-53
  • [arch] archcareers.org; (AIA, AIAS); 2009. – /archoverview.html
  • [hend] ‘Project Management For Construction’; Hendrickson; 2003. – ch. 1, ch. 3
  • [idso] ‘Quake III Arena’; id Software; 1999.
  • [sei] ‘Published Software Architecture Definitions’; SEI; 2009.
  • [pahl] ‘Engineering Design: A Systematic Approach’; Pahl, Beitz, Feldhusen, Grote, Wallace (ed/trans), Blessing (ed/trans); 2007. – part 1.1.1
  • [bucc] ‘Engineering Mechanics For Structures’; Bucciarelli; MIT, 2002.
  • [hend2] ‘Project Management For Construction’; Hendrickson; 2003. – ch. 3.1, ch 1.6, ch 1.8, ch 1.4, ch 1.9
  • [shaw] ‘Prospects For An Engineering Discipline Of Software’; Shaw; 1990.
  • [denn] ‘Is Software Engineering Engineering’; Denning, Riehle; 2009.