I’ve received some feedback privately questioning both the validity and necessity of my attempted definitions of artefacts, products and design documents.
One objection was to my statement that machine-executable code is the artefact. I think that this was, at worst, a simplification. It would be more accurate to say that the artefact is formed by the combination of a general-purpose computer with the machine code necessary to turn it into a special-purpose machine. This seems consistent with the computer science theory around Universal Turning Machines and is the justification behind allowing patents on software, so I feel this is on reasonably solid ground. Machine code may only be a component of the artefact, but it’s the part that changes.
Another objection I think was fair. I wrote that source code is not an artefact, but a design document. It would perhaps have been more accurate to say that source code is not the artefact—the one that end users actually receive. The emphasis should be on the fact that source code is a design document, an idea that is explicitly rejected in the current thinking about ‘software engineering’.
Let us accept for a moment the definition of an engineer as the artisan minus the worker. (This is probably controversial; many people see engineering as having developed by adding something—science—to the artisan, not by taking something away.) In this model there is a division at some point between the work of the engineer above and that of the worker below, and communication across the boundary is through design documents. The debate boils down to a disagreement over where this line should be placed.
The widely accepted definition of ‘software engineering’ holds that only the ‘software architect’ is above the line, code monkeys are below and the design documents passed down are at the level of UML diagrams. The craft movement wishes to erase the line altogether. My contention is that everybody is above the line and that we communicate to the compilers below through source code.
You could make a valid argument that all engineering, including software engineering, is a craft. If fact you could argue that anything humans do is either a craft, has been automated or is about to be automated. You would, however, now be arguing about what happens above the line, not in the system as a whole. It follows that the lessons learned by engineers over the centuries can be applicable to software engineering, though not, I submit, in the way we have always been told.
Zane Bitter writes:
I’ve received some feedback privately questioning both the validity and necessity of my attempted definitions of artefacts, products and design documents.
One objection was to my statement that machine-executable code is the artefact. I think that this was, at worst, a simplification. It would be more accurate to say that the artefact is formed by the combination of a general-purpose computer with the machine code necessary to turn it into a special-purpose machine. This seems consistent with the computer science theory around Universal Turning Machines and is the justification behind allowing patents on software, so I feel this is on reasonably solid ground. Machine code may only be a component of the artefact, but it’s the part that changes.
Another objection I think was fair. I wrote that source code is not an artefact, but a design document. It would perhaps have been more accurate to say that source code is not the artefact—the one that end users actually receive. The emphasis should be on the fact that source code is a design document, an idea that is explicitly rejected in the current thinking about ‘software engineering’.
Let us accept for a moment the definition of an engineer as the artisan minus the worker. (This is probably controversial; many people see engineering as having developed by adding something—science—to the artisan, not by taking something away.) In this model there is a division at some point between the work of the engineer above and that of the worker below, and communication across the boundary is through design documents. The debate boils down to a disagreement over where this line should be placed.
The widely accepted definition of ‘software engineering’ holds that only the ‘software architect’ is above the line, code monkeys are below and the design documents passed down are at the level of UML diagrams. The craft movement wishes to erase the line altogether. My contention is that everybody is above the line and that we communicate to the compilers below through source code.
You could make a valid argument that all engineering, including software engineering, is a craft. If fact you could argue that anything humans do is either a craft, has been automated or is about to be automated. You would, however, now be arguing about what happens above the line, not in the system as a whole. It follows that the lessons learned by engineers over the centuries can be applicable to software engineering, though not, I submit, in the way we have always been told.