

Don’t build. Compose - 2t
https://medium.com/on-startups/305a31ff609

======
gbvb
Software development is like movie making: [http://www.silicon-
stories.com/movie-making-software-develop...](http://www.silicon-
stories.com/movie-making-software-development.php)

Software architecture is like city planning:
[http://www.windley.com/archives/2003/09/enterprise_arch_4.sh...](http://www.windley.com/archives/2003/09/enterprise_arch_4.shtml)

Software development is not like manufacturing:
[http://www.codinghorror.com/blog/2006/10/is-software-
develop...](http://www.codinghorror.com/blog/2006/10/is-software-development-
like-manufacturing.html)

Software development is like manufacturing:
[http://www.amazon.com/exec/obidos/ASIN/0321150783/codihorr-2...](http://www.amazon.com/exec/obidos/ASIN/0321150783/codihorr-20)

I believe that software development can be disciplined (development of missile
control systems, payroll systems) or be agile (instagram, pinterest,
facebook...). I think it all depends on what is considered to be the most
valued resource for the organization and the software it is planning to
build/compose/manufacture/make.

If we value system resources (real time constraints, compliance, SLA), we tend
to be more like building systems. If we value end users experience in the
final outcome, it tends be agile and take the notion of the movie/novel et al.

~~~
ericedge
I agree there's a range, but if you have to abandon an analogy to describe
another end of the range, then it's time to find a new analogy. I think one
trap in the article's logic is thinking that all structural engineering is at
the scale of bay-spanning bridges or skyscrapers. Structural engineering can
range from structures that withstand earthquakes down to a shack to stash your
garden tools--just because one end of the continuum requires more rigor than
the other doesn't make them unrelated.

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

------
daniel-cussen
A counterpoint: I write algorithms. I don't have customers that come to me
saying, "I want an external sorting algorithm that is tuned to SSDs and
APU's;" rather, I take an existing question or open problem, mull it over,
arrive at another question, find a few answers along the way, and eventually I
find a way to map the math to the metal. It's bottom up, usually, and
generally, rather than composing something deeply personal, I eliminate
touches I identify as personal until there's nothing of me left in the
algorithm. So what I find illuminating about this post is not that most
software is unlike building bridges, but that what I do is like building
bridges. See also, <https://news.ycombinator.com/item?id=3575449>

------
obviouslygreen
I question the notion that, just because the terms we use match up with
another discipline (and this is likely not the only one), we are necessarily
drawing a direct comparison with that other discipline by using those terms.

Programming/development/whatever is full of ridiculous terms. We co-opt them
from anywhere we want, we make them up, we apply them in multiple outlandish
ways. We don't really need a reason, because "we" in this case means "people
who decide what to call things," and it's not as though we have a _Bureau of
Naming for the Computational Applied Sciences_ running around forcing us to
use good metaphors.

I can see it being fun to throw around theories about how we came to use the
various terms that occur in our field, but I definitely don't see them as
being strict (or even, in most cases, loose) direct references to the same
terms' usage in other fields. Sometimes a term works for someone; sometimes
the generic terms that work for different people line up in ways that make
sense in more than one context.

This just reads too much into that.

~~~
seanlinehan
I surely agree with you in the general, but I enjoy the line of the thinking
that the OP is going down. The way I see it is that the language we use
dictates how we think about problem solving. Even if we don't port the strict
definition of a term one-to-one, we are still anchoring our approach to the
mind-space that the other term occupies.

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.

------
ZirconCode
Similarly, you could look at what an Artist does with a painting.

I think looking at coding as an art has a few fundamental problems however. It
may be extremely appealing to aim for beautiful and elegant code, but it
doesn't satisfy the goal of coding. Code has a need of being practical, of
working. It is a balance between function and form. I think going to far in
either direction will not pay off in most cases. Too much time is either
wasted writing a piece seen as acceptable, or re-factoring the code at later
stages.

~~~
jabbernotty
As someone who works as a software engineer and paints for fun, I've used the
analogy once or twice. But it only holds a little.

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.

------
twerquie
The problem with the novel authorship metaphor is that it's too close to the
literal act of authoring software to be useful. The terms involved in the
metaphor (author, editor, publisher, composition, rewrites, etc) all have more
specific literal meanings and are therefore confusing. A metaphor should be
properly removed from its subject to inspire objectivitity.

------
kaiwetzel
For those who haven't seen one of the "tire swing" cartoons mentioned in the
article: <http://www.projectcartoon.com/create/> and some historical versions:
<http://www.businessballs.com/treeswing.htm> :)

------
gyepi
I would agree that certain aspects of programming is quite similar to writing.
Both require a certain command of the raw materials and good taste and
judgement in how to assemble those materials into finished form. The analogy
works because these are general statements that could apply to many kinds of
creative endeavors. However, as soon as one gets so specific as to map the
roles of "product guys" and "engineers" and "editors" and "authors", the
analogy has long since left the room.

Though I don't think that this analogy fits well, I applaud the OP for it;
this kind of analogical thinking is, after all, thinking about what he does
and how it relates to other other aspects of life.

------
hxa7241
Let's not confuse product with implementation.

Someone still needs to choose and arrange data-structures and algorithms to
fit available resources. That is engineering. Just because the product is ill-
defined and subjectively-judged does not lessen that.

You might want an _architect_ to be sensitive to aesthetic/political/whatever
concerns, but you pay the _engineers_ to make sure the thing stays standing
up. Does a building stand up because of story-arc and character development?
No, it is because of understanding of physics and materials. The same holds
essentially for getting computation done within time and space.

------
snorkel
I like this writing analogy a lot, because software is subjective. Doneness is
subjective according to how its creators define it. User experience is
subjective. Even overall quality depends on consensus opinion. Software is an
art form.

------
dllthomas
<http://en.wikipedia.org/wiki/Literate_programming>

------
L0j1k
To someone that doesn't actually write code, sure, it may be just that easy to
use terminology alone to draw the parallel.

~~~
new299
Your comment seems unduly negative. But, after reading the article it really
does seem like a forced analogy.

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.

~~~
L0j1k
I think that's what struck me most about this, that it felt forced, and also
written by someone that doesn't quite understand exactly what programming
actually is and is not. Writing a novel? No. I'd say it's much more like
building a bridge than writing a novel. We use small machines to build a
bigger structure that serves a purpose. That's why I accused the author of not
knowing much about programming (indeed, he is a self-described "product guy").
Otherwise he'd be much more likely to draw parallels with building bridges or
some other kind of engineering than writing a novel or authoring some other
literary product.

