In which I attempt to show the software development process is more appropriately characterised as a form of engineering than as a craft. I argue that resistance to this idea this stems from an understanding of ‘software engineering’ based on a definition concocted by people who understand neither software nor engineering.
2 Dec 2014 19:26
Thanks to @hoorayimhelping for pointing it out.
diff -r 66f11c722f84 -r de6ca23b4039 essays/reclaiming-software-engineering.txt
--- a/essays/reclaiming-software-engineering.txt 2011-03-14 01:26:13
+++ b/essays/reclaiming-software-engineering.txt 2014-12-02 19:26:14
@@ -37,7 +37,7 @@
The temptation is strong to declare that this reliability-obsessed process is not engineering at all, but it must be resisted. I do not claim that _all_ software is engineered, at least in the modern sense. Yet so long as we are developing software within a social context, where the finished artefact has users other than its designers, we can scarcely escape the conclusion that what we are doing is engineering. Still, I would certainly argue that methodologies that disregard the expenditure of resources are the antithesis of _good_ engineering.
-If I wished to be kind to the [SEI | Software Engineering Institute], I would note only that the context in which they operate is not shared by most---or even many---software engineers, and that they could do us all a favour by choosing a name that does not imply that they represent the only way of doing software engineering. If I were feeling less charitable, I might add that even in their chosen context their methods have proven [conspicuously unsuccessful][http://www.baselinemag.com/index2.php?option=content&task=view&id=16&pop=1&hide_ads=1&page=0&hide_js=1 The Ugly History of Tool Development at the FAA].
+If I wished to be kind to the [SEI | Software Engineering Institute], I would note only that the context in which they operate is not shared by most---or even many---software engineers, and that they could do us all a favour by choosing a name that does not imply that they represent the only way of doing software engineering. If I were feeling less charitable, I might add that even in their chosen context their methods have proven [conspicuously unsuccessful][http://www.baselinemag.com/networking/The-Ugly-History-of-Tool-Development-at-the-FAA/ The Ugly History of Tool Development at the FAA].
* * *
14 Mar 2011 01:26
diff -r 5e4e081eab50 -r 66f11c722f84 essays/reclaiming-software-engineering.txt
--- a/essays/reclaiming-software-engineering.txt 2010-04-12 09:20:09
+++ b/essays/reclaiming-software-engineering.txt 2011-03-14 01:26:13
@@ -33,7 +33,7 @@
The most prominent example of this school of thought is the unfortunately-named Software Engineering Institute at Carnegie Mellon University. It is funded by the United States Department of Defence, whose bizarre procurement policies treat designs and artefacts identically. Unsurprisingly, the [SEI | Software Engineering Institute] tends to label ideas that fit its patron's worldview as 'software engineering', even when they may be the opposite of established engineering practice.
-One form this takes is the fetishisation of _reliability_ over all other properties of a system. To the mechanist, the fact that software sometimes crashes is damning evidence that software is not yet an engineering discipline. In part this is coloured by an unjustifiably narrow view of the range of work in which engineers are engaged. Pencils and paperclips break all the time.[* Henry Petroski, [Invention by Design] (Harvard University Press, 1996).] Even in areas where safety of life is an issue---popularly assumed to be the sole province of engineers---failures still occur absent any negligence on the part of engineers.[* Henry Petroski, [To Engineer is Human] (Vintage Books, 1992), pp. 5--6.] To assume that software is unique among humanity's creations in its tendency to fail is to ignore both the evidence and the more prosaic explanation: that the cost to society of ensuring it never can usually outweighs the cost of taking the risk.
+One form this takes is the fetishisation of [_reliability_][../is-it-safe Is it Safe?] over all other properties of a system. To the mechanist, the fact that software sometimes crashes is damning evidence that software is not yet an engineering discipline. In part this is coloured by an unjustifiably narrow view of the range of work in which engineers are engaged. Pencils and paperclips break all the time.[* Henry Petroski, [Invention by Design] (Harvard University Press, 1996).] Even in areas where safety of life is an issue---popularly assumed to be the sole province of engineers---failures still occur absent any negligence on the part of engineers.[* Henry Petroski, [To Engineer is Human] (Vintage Books, 1992), pp. 5--6.] To assume that software is unique among humanity's creations in its tendency to fail is to ignore both the evidence and the more prosaic explanation: that the cost to society of ensuring it never can usually outweighs the cost of taking the risk.
The temptation is strong to declare that this reliability-obsessed process is not engineering at all, but it must be resisted. I do not claim that _all_ software is engineered, at least in the modern sense. Yet so long as we are developing software within a social context, where the finished artefact has users other than its designers, we can scarcely escape the conclusion that what we are doing is engineering. Still, I would certainly argue that methodologies that disregard the expenditure of resources are the antithesis of _good_ engineering.