I think the most interesting thing about what you’ve said is here:

“While creativity and elegance are desired there is no escaping the fact that the vast majority of serious development needs a rigourous approach and anything else is bound to end in tears…”

And I think that’s most interesting because it indicates that creativity and the arts are by necessity not rigorous. This may be true in some areas, but sculptors have to think (and sometimes do complex math) to figure out how the weight of their creations can be supported given the materials they have.

Writers can be subject to some rather rigorous limitations too. Take the Sestina for example, widipedia describes the requirements of the sestina this way:

“A sestina (also, sextina, sestine, or sextrain) is a highly structured poem consisting of six six-line stanzas followed by a tercet (called its envoy or tornada), for a total of thirty-nine lines. The same set of six words ends the lines of each of the six-line stanzas, but in a different order each time; if we number the first stanza’s lines 123456, then the words ending the second stanza’s lines appear in the order 615243, then 364125, then 532614, then 451362, and finally 246531. This organization is referred to as retrogradatio cruciata (“retrograde cross”). These six words then appear in the tercet as well, with the tercet’s first line usually containing 1 and 2, its second 3 and 4, and its third 5 and 6 (but other versions exist, described below). English sestinas are usually written in iambic pentameter or another decasyllabic meter.”

That’s a pretty rigorous structural form ;)

You make several good points. As far as I’m concerned the “Architect” or “Engineer” label is a metaphor, which is fine and good, and provides some illumination as long as it remains a metaphor. But, the problem is that people have stopped seeing the metaphor, partly because they don’t actually know what engineers do, and partly because computer programmers have a strong tendency to take metaphors literally.

So on that level “Software Writer” is no better, except that it’s more obviously metaphorical than the alternative. But really, what I want is a label tells us that software creation is primarily a communicative act. I like the “build stuff that works” connotation of engineer, but it’s only part of what we do, and I think a lot of “software engineers” can be seduced by it into ignoring the “communication” part and failing to write readable, maintainable, code.

And I’d like to mention that any discipline requires communication about complex ideas in order to perpetuate itself — that does not mean that communicating complex ideas is at the core of the discipline the way that it is for software development, or writing, or for that matter philosophy.

The point is that engineers rarely build a “thing”, with the obvious exception of prototypes in small shops (technicians typically build the actual prototypes and give us 8 kinds of grief the moment we pick up tools).

I also think that “the exception that proves the rule” should be your guideline. Engineers typically produce *drawings* and parts lists, that should be specific enough to build equipment. Some of it is going to be software-like in that it isn’t interpreted by humans (gerber files produce PCBs, CNC output straight from Pro-Engineer) but much of the work is done on production (or construction) floor by humans.

The catch is that the “why of this” is never transmitted, and only considered when a human might decide that your unorthodox decision is just a typo. This is largely because changing the design once shipped is so vastly higher than in software that it is not considered important. It has nothing to do with the complexity of thought needed to produce the thing, just that reproducing the complexity of thought is unlikely, and a small part of the cost to pay if it is needed.

I always get a bit worried when people start trying to put software development in the ‘arts’ box. While creativity and elegance are desired there is no escaping the fact that the vast majority of serious development needs a rigourous approach and anything else is bound to end in tears (or websites written in PHP, which is basically equivalent :P )

But then, I think some typical engineers are Leonardo, Wittgenstein, St. Exupery, Rowan Atkinson — see the slides about engineers at http://www.aleax.it/scipy_key08.pdf — so of course I’m proud to call myself an engineer (that’s also what my degrees say I am, and I passed the State Exam officially making me an Engineer in Italy…). See also http://aleaxit.blogspot.com/2008/09/scientist-and-engineers.html for more, similar thoughts…

Eventually, I began to see my activity of writing tickets as essentially the same as programming but with a more elastic language and some really smart compilers at the other end.

I could trust my developers to do the right thing as long as I set the parameters clearly. But if I couldn’t give them enough specifics, then they would come hassle me for more detail, sort of like when the interpreter raises an exception.

Or even worse, maybe they wouldn’t come hassle me, but their output wouldn’t be what I needed. Ultimately, it all came down to how well I could write the ticket at the beginning. Their failures were almost always linked to ambiguity in the original assignment.

Anyhow, I think journalists have been in this zone of thought for a long time. They have to explain complex stories clearly and tersely.

Every programmer should read Strunk’s Elements of Style at least three times. Just substitute the word “method” whenever the text says “paragraph” and “code” for “words” and it makes for brilliant advice. For example:

After the paragraph has been written, it should be examined to see whether subdivision will not improve it.
Omit needless words.
Keep related words together.

And there’s lots of other good ones.

I agree it’s about levels of abstraction more than syntactic sugar in the language — though syntactic sugar generally exists as a way of encoding an abstraction at the language level and often a way of developers to create simplified representations of new abstractions. (I’m thinking of operator overloading, or python decorators.)

And I agree with both you and steve — writing for the alien “intelligence” of the computer makes this hard. But I think that the requirement that what we write must also fit the human brain is what makes things *really* tricky.

I’m not arguing that engineers don’t have to communicate with others, but that the end result of their work isn’t generally a document, but a thing. They work to build stuff that works, and communication is part of the process, but with software “engineering” the document itself is the result.

And I’ve worked with a lot of materials engineering people who aren’t primarily concerned with building bridges, but with determining the tensile strength and wear characteristics of particular composites.

They do lots and lots of math, and build something once and it is pretty darned sure to work. We do no math, build something over and over, when we find bugs. So, there are lots of differences between what I do and what my “real” engineer friends do. So, I’m struggling to find better metaphors for what we do.

Think of building a bridge: the plans aren’t there to instruct the “bridge-building machine”, they are there to communicate to the site staff how to put a phenomenally complex assembly together so it continues to stand after 100 years.

If anything the differences in software engineering come about because of the stupidity of the computer: our instructions have to be precise because no intelligence can be brought to play in their interpretation.

Jim Arlow has it right, I think. Computers are TOMCATs: Thoroughly Obedient Moron, Cannot Actually Think, and this makes the need for rigorous thought in design even more critical.

Looking at the history of programming, it has been one of continual increase in the level of abstraction that we can operate at when we try to communicate our intent to computers. Originally it was wires and switches (the software was literally hard-wired), then binary, assembler, compilers and “high level” languages. The next level is to compile code from models. This is already happening. Several of my clients compile 100% of their code, test cases, instrumentation and documentation directly from models.

As William Gibson said – the future is already here – it’s just not evenly distributed.

Definition of Engineer: a person who designs, builds, or maintains engines, machines, or public works.

We face a problem and design, build and maintain the solution/software. So I gladly call myself a “Software Engineer”.

http://www.literateprogramming.com/