Just say no to “software engineering”

I was reading Jacob Kaplan-Moss’s blog article on “syntactic sugar” and I realized that there’s something sitting just below the surface of what he’s saying, something important, something counter to the standard “software development is an engineering discipline” view of our work.

Jacob rails against those who say the differences between modern computer languages amount to nothing more than “syntactic sugar.” Ultimately he argues that: Syntactic sugar matters.

Sure it makes no “technical” difference but it does make a huge difference — because it changes the way we think about writing software.

I’ll loop back to that in a second, but first a quick detour through another recent blog post:

Eventually you come to realize that in order to truly succeed, you have to write programs that can be understood by both the computer and your fellow programmers.

Of all the cruel tricks in software engineering, this has to be the cruelest…. Even when you’re writing code explicitly intended for the machine, you’re still writing. For other people. Fallible, flawed, distracted human beings just like you. And that’s the truly difficult part.

Jeff Attwod

The thread that ties both of these together is that they highlight the way that people and by people I mean software developers, tend to forget is that code is always two things:

  • A series of instructions or declarations processed by a computer.
  • A series of instructions or declarations processed by one or more human beings.

Code is a machine construct, but it’s also a social construct. Software engineering is a strange name for our discipline, since the hard work of programming isn’t just getting code that machines can run, but in creating abstractions that allow human beings to learn, understand, and evolve the code over time. We didn’t invent Structured Programming, or Object Oriented Programming because they help the computer understand what we mean — we created them because they provide us with tools to help us as human beings to be able to understand the code we write.

Non-software Engineers aren’t concerned primarily with the practice of communicating complex thoughts and ideas to others. This is a vast oversimplification, but I think it’s fair to say that they are interested in constructing mathematical models of how things things behave, so that they can build stuff that works.

But that’s not what we are, we are creative writers, we invent new ways of thinking about the world, and we try to communicate them to each other every day.

Software Engineers do create incredibly complex systems, and operate under constraints that other writers do not — what we write has two audiences, one human, and one non-human. Writing for the non-human audience alone will result in code that’s incomprehensible to other programmers, but the opposite is also true. Computer programming is hard — and it’s hard for a very specific reason — because it requires thinking like other people, and not thinking like people at all.

Fortunately, the problem is simplified a bit by the fact that other programmers have learned at least somewhat to think like silicon and metal, so you can lean a little bit in that direction and still be understood. But still you have a very exacting, very alien audience, and a very exacting, very human one — and programming languages must be designed to balance the needs of both.

So, perhaps we ought to stop calling ourselves software developers, software architects, or software engineers, and start calling ourselves software writers.

16 Responses to “Just say no to “software engineering””


  1. 1Mike Lowe

    I would say software poet is even better than software writer. Writing things that a machine and an person can understand reminds me of the restrictions poets have, think iambic pentameter.

  2. This seems like an idea related to “Literate Programming” a concept led by Donald Knuth since the early 1980′s (or earlier).

    http://www.literateprogramming.com/

  3. 3Travis Jeffery

    I’ll take “Software Engineer” over anything else any day. “Software Writer” sounds way too close to being able to be lumped in with people in Humanities.

    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”.

  4. It seems to me that the real issue is about different levels of abstraction rather than syntactic sugar. Humans simply don’t operate comfortably at the levels of abstraction that computers currently require. All types of human writeable/readable code are simply mechanisms to bridge this abstraction gap so that we can communicate our intentions to computers in a way both we and they understand.

    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.

  5. I can’t agree that other engineering discplines aren’t concerned about communication with others. In fact the difference in programming is that our instructions also have to be understood by the alien in our midst: the computer.

    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.

  6. Steve,

    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.

  7. Jim,

    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.

  8. Great post. I found when I managed a team of developers that the system worked best when I wrote assignments as carefully and explicitly as possible. In other words, I would put in requirements like “this page view should generate at most 3 database queries” or “Do not copy-paste and then edit code from that module here. Instead, rewrite the other one to support its original use and this new one”.

    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.

  9. So why do you think “architect” is inappropriate? Doesn’t the architect of a building have to effectively communicate, non-verbally, with all the humans that will be interacting with that building for years to come, as well as all the humans that cooperate to erect that building — while working within all the constraints imposed by nature and the applicable technology, so the building will remain standing (perhaps, as in the case of Renzo Piano’s airport terminal at Kobe, will stay standing even through an earthquake so intense as to raze the city itself)…? Soliditas, utilitas, venustas (with all the due quibbles about how these priorities should be ordered, of course) — robustness, usefulness, delight; aren’t these our goals, just like Vitruvius’ (the archetypal engineer) or Leandro Alberti’s (the archetypal architect)?

    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…

  10. 10nnp

    I think this is quite a subjective thing to be honest. Writing code that is readable does not mean you can’t take an engineering approach to the entire problem. In fact, changing your title because you’ve decided to change your code so that it’s now more readable would be a bit like a construction engineer changing his title because he bought a new pair of steel toed boots.

    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 )

  11. 11wumpus

    Re: Steve’s point

    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.

  12. Alex,

    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.

  13. NNP,

    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 ;)

  14. Great and timely piece. It seems to me that much of the talk of Domain Driven Design these days underscores this importance of the craft. Code readability serve the business subject matter expert as well as your fellow software artisans.

  15. 15jefurii

    i bet william gibson could do something really wacked out and cool with this idea.

  1. [...] for a while now that software engineering is a social activity … and now Mark Ramm picks up a similar bone and points out that software development is really building a product to be understood by both a [...]

Comments are currently closed.