Don’t build. Compose

In software engineering there are still rigorous requirements in fields that run software on other planets or in medical systems, but there's software with looser requirements as well.

The best metaphor I've encountered for the wide variety of software engineering was a talk that covered the book "How Buildings Learn" http://www.amazon.com/How-Buildings-Learn/dp/0140139966 -- there are structures that favor adaptability, and others that favor rigor, but that doesn't mean that structural engineering doesn't happen on one end of the continuum compared to the other.

(To be fair, there are rigorous forms of writing, too, but I think restricting the analogy to only novels is too narrow to be effective.)

I read this post is as saying that we are no longer using the appropriate metaphors -- we are anchoring on counter-productive terms. These metaphors clearly were relevant at some point, but the field in which product developers play in has changed dramatically. If the game has changed, then it would seem that anchoring our language on new metaphors would make sense. If we use strong metaphors that more closely resemble the work we are doing, it could help us accelerate our problem solving.

As with all ideas, we will see if others agree with the OP. Personally, I think the newly proposed metaphor of composition is more descriptive than that of building.

In fact, I think the article only manages to make the architecture metaphor appear more fitting. Even when you're building a bridge, you never really "put in the last rivet and make the last weld." Read about any historic bridge and you'll quickly learn that the life of a bridge can be as dynamic as any novel. London bridge was redesigned and rebuilt (refactored?) on several occasions since Roman times. The Brooklyn Bridge was conceived by a man, continued by his son, and completed by his daughter-in-law.

It holds in the sense that most of the time you start with an empty canvas. You use the tools you have at hand or the tools you wish to learn more about. You tend to plan ahead enough to prevent structural mistakes, to make sure your work comes out the way you envisioned it. It holds in the sense that only 'a fellow artist' can begin to understand the details of what you did and how that fits or doesn't fit in the work at large. It holds in the sense that you shouldn't ever start out with the details when performing either activity.

When you code something you do it to specification, which could be analogous to one being contracted for a particular piece of art.

The coding and art analogy doesn't hold when I consider the emotions that shape my art and drive me to create it that way, and the different result that it has on different people when they pay attention to it. It doesn't hold when I look at how one does flesh out detail. I myself start out with a general sense of the space that an entity will not be occupying. I describe that space in more and more detail until it approaches the space that it will be occupying. Then I can start placing marks that describe the details of that entity, in increasing detail. Programming has no analogy to that as far as I'm aware. It also rarely holds when you consider particular methods such as the 'test' part of test driven development.

This is probably something that only applies to me though, because everybody who programmes or paints has their own way of working.

I suppose in some ways it's quite surprising that writing code is so much different than writing a novel. They are after all linear sequences of statements. But a novel is always trying to draw you toward the end, to a conclusion. The lasting ideas it places in your mind, it does using indirect means. A computer program on the other hand creates something dynamic and non-linear.

What surprised after reading the article is how little I felt writing code, even narrative driven games, is like writing a novel.