

Software is nothing but design - mcormier
http://agilefocus.com/2009/09/14/the-myth-of-undesigned/

======
smokinn
I disagree.

Software is far from 100% design. I'd give it 60 or 70% design at best and
even then only in the relatively small (though growing) web sphere.
Personally, in my career spanning largely web app development, I've found that
having an up-front design and simply filling in the back end code is the most
pain-free way to go. This still doesn't make the design 100% though. Let's be
generous and call the design 90%. There still needs to be working code behind
the design.

The other way, as he pointed out is what leads to unusable junk that makes the
life of everyone involved (the coder, the designer, the user) painful. When
the coder takes it upon himself to make a "temporary" design, it more often
than not ends up permanent. This is definitely the worst way to go. I've
committed this sin before and learned from it (I'm a terrible designer) but
this doesn't have to be the way to go.

If, for some reason, I don't have a designer (and stakeholder!) working
closely with me (which is now a warning bell in itself), I can flesh out the
main requirements of what needs to be done as far as major features go and
design a public api to my software. When I finally get a design, I'll have
only the minor features and the integration of my major api calls to do. In
this case SaaS is a blessing. (As an added bonus it makes it easy to swap out
or rewrite your major features as you hit performance bottlenecks.)

~~~
wpietri
I think you misunderstood what I meant. That's my, fault, though; the bit
about software being pure design wasn't my main point there, so I kept it very
short. Plus, people use the word design to mean a zillion things. I'm using
the word in its broadest sense.

Even if I'm making something with no user interface at all, creating source
code is still purely a design activity. The source code doesn't actually do
anything; it's a blueprint. When you create the UI, that's designing the UI.
When you create the API, that's (as you say) designing the API. Even when you
implement the guts, you're still designing them as you go.

I agree with everything else you say, though, especially about the warning
bells!

------
gdp
Using the word 'blueprint' is a bit deceptive. Source code is _not_ a
blueprint, because it is the end result. A blueprint provides all the
information we need to build the house, but we can't live in a blueprint (i.e.
a blueprint does not fulfil the same needs as an actual house, even though
they describe the same thing). We can 'validate' our (now-built) house against
our blueprint using a tape measure and a spirit level.

In software, the only analogous process we have is formal specification and
mechanical verification.

Just to be entirely clear, _code_ is not a "specification" because to suggest
that it is would be like building a full-scale model of a house as a
'blueprint'. If the blueprint is functionally identical to the thing it is
describing (i.e. you can live inside the blueprint just as well as you can
inside the house it describes), then it's not a "specification" (or a
"blueprint") in any useful sense.

So I don't even really have an opinion on the "software is design"
explanation. I don't think of software like that, because I don't generally do
"exploratory coding". Rather, I'm just objecting to the (often abused) notion
of software having anything analogous to a blueprint.

~~~
wpietri
Source code is in fact not the end result.

If it were, we wouldn't care so much about non-functional aspects, like
spacing, variable and method naming, and code organization. It's a design
document. It's special, though, because it is the only design document that
the computer can, after processing, understand.

The end result is not the code. It's what happens on people's screens, and in
people's worlds after we tell the computer what to do.

------
gruseom
The point made in this article is associated with Jack Reeves' classic 1992
essay on source code as design.

[http://www.developerdotstar.com/mag/articles/reeves_design.h...](http://www.developerdotstar.com/mag/articles/reeves_design.html)

~~~
wpietri
Faantastic. Thanks for that link; I had never read this.

------
DanielStraight
This is a really good point.

------
known
"Show me the code" -- Linus

------
DanielBMarkham
I wish I could upvote this twice.

"Design" "Architecture" and "Analysis" have somehow entered this strange place
where we talk about them as if they're not related to "real code"

Instead, as the article points out, _it's all design_. The only difference is
which layer of abstraction we're working at. You can make a nice object model
by simply kicking out some header files in C, or by declaring some types in
OCAML.

We've had so many metaphors -- the factory, the construction site, the
military plan -- that we've lost track of just what it is we're doing. And it
doesn't help that these buzzwords have generated their own job roles, books,
and cultures.

