Why Writing Software Is Like Engineering

How would you classify writing software? Is it science (as in computer science), a form of art (as in code is poetry or prose) or an engineering discipline? Terence Parr, a professor of computer science at the University of San Francisco, recently wrote about why writing software is not like engineering. Terence concludes that writing software is more an art than an engineering discipline:

Writing software is most similar to writing fiction novels. Writing novels is also an act of creation in an unconstrained and ethereal medium with few well-established construction rules.

I find this notion to be a fallacy, because writing software can be looked as a form of art, but it is largely driven by engineering. Programming can be called a craft or an art-form, but the software itself is not. My biggest argument in this context is regarding automation. Engineering primarily promotes automation of tasks. Most software is written to automate manual or semi-manual processes and enforce computational validations. However, we cannot automate art. A painting won’t automatically self-render itself into a 3D landscape. Nor would the premise of a fiction novel evolve or extend on its own, like refactored source code or OOP libraries can allow for in software.

It has become quite clear in the software world that a big design up-front doesn’t work. Engineering can solve this problem through iterative design and development. Art, on the other hand, cannot be progressive by its very nature. The final result of art is static, albeit beautiful or enjoyable.

Recently I heard Neal Ford talk about Emergent Design during a brown bag session at work. Neal is an author, a speaker and a Software Architect at ThoughtWorks. In his talk, Neal questioned the nature of code? What is software code? I think it’s a subtle yet very important construct in the understanding of software engineering.

A conventional engineer’s output, be it mechanical, aeronautical or any other branch, is the design or the blueprint. The engineer provides the very basis of objects architecture and its inner-workings. But what is the output of a software engineer? Yes, our lot designs architectures too and we also document the inner-workings (as much as some of us hate to). But the primary output of a software engineer is — the code. Hence, software code is the core output of a type of engineering, not a type of art.

To further draw the “art of engineering”, I’ll leave you with an interesting anecdote to ponder on:

Warning! If you still enjoy playing PacMan, don’t read the next paragraphs—they will ruin it forever for you. Sometimes knowledge comes with a price.

Consider the PacMan console game. When it came out in the 1970s, it had less computational ability than a cheap cell phone of today. Yet, it had to solve a really difficult math problem: how do you get the ghosts to chase PacMan through the maze? That is to say: what is the shortest distance to a moving target through a maze? That’s a big problem, especially if you have very little memory or processor power to work with. So the developers of PacMan didn’t solve that problem, they used the anti-object approach and built the intelligence into the maze itself.

The maze in PacMan acts like an automata (like in Conway’s Game of Life). Each cell has simple rules associated with it, and the cells executed one at a time, starting at the upper left and proceeding to the lower right. Each cell remembers a value of “PacMan smell.” When PacMan sits on a cell, it has maximum PacMan smell. If he had just vacated the cell, it has maximum PacMan smell –1. The smell degrades for a few more turns, then disappears. The ghosts can then be dumb: they just sniff for PacMan smell, and any time they encounter it, they go to the cell that has a stronger smell.

The “obvious” solution to the problem builds intelligence into the ghosts. Yet, the much simpler solution builds the intelligence into the maze. That is the anti-object approach: flip the computational foreground and background. Don’t fall into the trap of thinking that “traditional” modeling is always the correct solution. Perhaps a particular problem is more easily solved in another language entirely.

Excerpt from the The Productive Programmer by Neal Ford. Art titled ‘Pacman Apocalypse‘ by Lawrence Yang.

6 thoughts on “Why Writing Software Is Like Engineering

  1. The comparison is an awkward one since software is a medium whereas art is a classification: “Writing software” is about the process, while “Writing fiction” is implicitly about the aim. Parr makes it clear, though, that when he refers to writing fiction he means the process – the idea that it’s constantly improvisational and unconstrained by physical reality. He is not suggesting, at least in that quote, that software is art.

    I also think your characterisation of creating art is a bit of a romanticisation. Writing a novel is certainly iterative – drafting, redrafting, etc. The fact is simply that most software has a utility, whereas art does not, and so whereas a thing with a functional purpose often suggests improvements to itself, art can’t be criticised in such a pragmatic fashion: there’s no obvious point at which it is “finished” (though that doesn’t stop people trying to upon improve it – see the constant retracings by subsequent artists over Leonardo da Vinci’s Head of Christ).

    I also don’t think there’s any reason why blueprints cannot be art. /Buildings/ can be art, so why can’t work describing the form a building will finally take be art?

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>