
Who Builds a House Without Drawing Blueprints? - luu
http://cacm.acm.org/magazines/2015/4/184705-who-builds-a-house-without-drawing-blueprints/fulltext
======
paulajohnson
I wrote a rebuttal of the "blueprints for software" analogy a couple of years
ago.

[http://paulspontifications.blogspot.co.uk/2013/01/software-h...](http://paulspontifications.blogspot.co.uk/2013/01/software-
has-civeng-envy.html)

TL;DR: Source code is the blueprint for software.

However that doesn't mean I completely disagree with Lamport's arguments.
Specifications are necessary in large-scale software because otherwise you
can't know if you have actually implemented everything the program is supposed
to do. When you release it the end-users get angry and insist that they told
you in that email / meeting / watercooler conversation last year how important
it was that the program frobnicate the warbles.

Lamport makes much of formal specifications. I agree that in some cases they
do add value; trying to prove the correctness of a distributed protocol in any
other way is dumb. But in my experience once you get up into application-level
requirements a formal specification is basically source code you don't know
how to compile; there is no formal correctness criteria against which you can
verify it, and the stakeholders can't understand it in order to verify it.

~~~
onion2k
The "source code is the blueprint for software" analogy doesn't work because
the source only tells you what the application _does_ , not what it's
_supposed to do_. There is no way to tell, from the source code alone, whether
or not what's been built is fit for purpose. You have to have some other
document. The "specification is the blueprint" analogy is saying that the
specification is a high level document that sets out what the application is
meant to do.

As an example, imagine you're paid $1m to assess my super awesome new
database. I give you the source code and tell you "the source is the
blueprint." After reading through the code you discover there's no DELETE
function. Have I built a clever immutable data store, or am I just an idiot
who forgot a critical function? _You can 't tell that from the source._

~~~
lambeosaurus
I agree with you both.

Technically the source is a blueprint. But this comes down to scale.

Among other things I've worked on banking and corporate management
applications. You cannot reason about the codebase at that scale. In these
instances it's not possible to have a good outcome without a blueprint.

Using the building metaphor, you can get away with building a bird feeder
without a blueprint. You can't get away with building a skyscraper without
one. Houses, maybe. Either way, high level blueprints help everyone.

~~~
br3w5
Good points - I think you need some kind of spec or something to reason about.
But I don't think it needs to be complete because it is easier to iterate on
software than buildings.

Taking the building metaphor, you can't clone a building locally and make
changes to it, then ask another builder to review them, suggest some changes
then push them out to a test environment before finally putting them into the
real world. So for me, the building metaphor only goes so far but there are
definitely some useful points in the article.

------
w4tson
TL;DR: The real problem to solve is the time to iterate.

I think it's a straw man argument. An unfair comparison. Buildings & bridges
etc have been designed and improved for literally thousands of years. Software
is a half a century old.

Aza Raskin's blog piece about human powered flight which bubbled up on HN has
always stuck with me[0]. "The problem is we don't understand the problem".

[0]: [http://www.azarask.in/blog/post/the-wrong-
problem/](http://www.azarask.in/blog/post/the-wrong-problem/)

------
spc476
I could make the argument that source _is_ the blueprint for a program. You
use blueprints to know how to build a building, and you use source code to
know how to build an executable, or rather, have a tool that automatically
makes the program from the blueprint (source code).

------
notacoward
What I've seen before, and seems to be the case in comments here, is that
beliefs about programming methodology are heavily influenced by what kind of
programming a person does. Those who work on small projects (i.e. few parallel
streams of development) love their agile/scrum/whatever. Those who work on
larger projects are less sanguine. Likewise, front-enders also love the hipper
methodologies, while back-enders tend toward the old school, independently of
whether their projects are large or small.

The confounding case is the Linux kernel, which is both large and systems-
focused but seems to eschew _both_ kinds of methodology in favor of undirected
chatter on mailing lists. Then again, maybe that's just part of a two-level
process. More than a few patches to the kernel have real specs behind them,
though developers don't call them that. They're just "kind of long, kind of
detailed" emails. This tendency to embrace a thing while rejecting the term
for it is one of the weirdest tendencies many developers seem to have.

------
MBlume
I know the author's entire argument doesn't stand or fall with the simile, but
it still needs to be said: blueprints are more necessary for physical
construction than they are for software because things made of wood and
concrete are hard to change part-way through.

~~~
pjbrunet
Not if you're a sculptor ;-)

~~~
dagw
I love that marble bust you just carved, it's perfect. Just one tiny little
detail, could you just make about 30% larger?

~~~
Ygg2
Also, I'd like to half of the statue transparent and the other half in the
form of a kitten? Oh and reflective. In red ink.

[https://www.youtube.com/watch?v=BKorP55Aqvg](https://www.youtube.com/watch?v=BKorP55Aqvg)

------
alvatar
It is very important to differentiate between House and Skyscraper. You can't
build a skyscraper (currently) without blueprints. But you can, and it has
been generally done, build houses without blueprints. It was even common to
build cathedrals without formal blueprints, by the way.

You can apply the same metaphors to software ;)

~~~
ams6110
I have built a house. You don't necessarily need professional blueprints but
it's a good idea to at least have a scale drawing of your floor plan.
Otherwise you won't really know how much of various building materials you
will need. How many windows? What size? Where will they be positioned? Will
they actually fit there?

Also from a practical standpoint you probably won't be able to get a building
permit without blueprints or drawings of some sort (though this varies).

------
WalterBright
Interestingly, blueprints are made in an iterative fashion much like software
is.

~~~
cfontes
Yeah but they are done before you actually start to lay any bricks.

In software you most of the time have the 2 things running parallel because of
time constraints and other business needs, which almost always leads to
failure.

------
fsloth
Once again I must refer to Naur's "Programming as theory building".
Effectively programming is implementing a specific model. For the outcome at
first release it does not matter how the model is documented - just that it is
_understood_ by the team. As time goes by, the more obscure the model is , the
harder it is to maintain the understanding within the team.

This probably one of the reasons some agile practitioners scoff at
documentation - if one is using the same framework to implement the similar
website time and again effectively the model remains the same and
understanding of the model is easy to retain and retrain.

------
reitanqild
Seems smart but this

> But few programmers write even a rough sketch of what their programs will do
> before they start coding.

deserves a reference to a study. (or, and this is the first time I use this
word: a #strawman flag.)

\- or am I the only one who sketches up data models and data flows before
going to work?

Also: Prototyping comes early in many other designs as well, often way before
detailed blueprints are signed off I think (not a mechanical engineer, just
outside observations).

In software it just so happens that prototypes are often made by the same
people and from the same material as the final product, only reinforced to
withstand production load and abuse.

~~~
falcolas
> am I the only one who sketches up data models and data flows before going to
> work?

Anecdata: Yes, or rather you're one of a vast minority. I work in an office
with no notebooks in the supply closet, and one 5x5 whiteboard which is
usually full of UX layouts.

------
th3iedkid
Though the idea on specs vs proof systems is good enough , one of the reasons
type systems are being studied is to actually make programming languages
themselves a good proof system , so much so that DSLs themselves become the
spec.

Proof systems have their uses and then there are places where they are just
too much.The best is in the mid!

>> "am the creator of the TLA+ specification language." I think TLA+ is/was
being used at Amazon [1]

Safety with Preservation and Progress guarantees of critical systems demand
design audits at a larger scale however if the scale of the program is
actually quite small , things like type-systems themselves are sufficient
proof of safety.

Ofcourse there are cases where even typing is too much!

One of the middlepaths is actually using inspection tools on code/programs as
another aspect altogether.

[1]:[http://research.microsoft.com/en-
us/um/people/lamport/tla/fo...](http://research.microsoft.com/en-
us/um/people/lamport/tla/formal-methods-amazon.pdf)

------
matt_s
I think the main thing missing in the discussion is organization or team size.
Given that the author is a CompSci researcher for the past 40 years he may not
be in touch with the reality of how organizations are structured and the
impact of that on software development.

If it is a start-up with 5 people, the software probably is the specification.
If it is a large organization of devs (25, 50 or 100 people), then you will
see more documentation, some of that specifications.

There is likely a threshold in the number of people where the number of
communication paths between them is too large to rely on informal ways of
communication. Maybe its 15-25 developers. The larger an organization is the
more bureaucracy gets introduced and you now have people whose role is to
write specs and requirements docs, etc.

------
javindo
Somewhat off-topic anecdote on this: my father in law designed a very rough
draft of "blueprints" for his parents new house in rural China (Xinjiang)
using MS Paint, local labourers built it in a few months and it's still
standing 10 years later!

~~~
hussong
From a European perspective, I like how you say that the house is still
standing 10 years later (and someone in another comment above mentioned 25
years) like it's something outstanding.

I would expect a house to last 100 years. A family member once bought a house
that is over 400 years old (and still standing).

Then again, construction and houses are way more expensive in Europe/Germany.
They're planning to tear down and rebuild my old high school from scratch,
current estimate: 85 million euros total.

~~~
maxerickson
It would be interesting to see a more rigorous comparison that took into
account size and what not, but here's the first Google result for "new high
school building", a $65 million project:

[http://www.monomoy.edu/page.cfm?p=931](http://www.monomoy.edu/page.cfm?p=931)

(A regional high school school for about 700 students, 168,000 square feet)

------
randartie
Higher quality version of this same talk (given at a different event):
[https://www.youtube.com/watch?v=-4Yp3j_jk8Q](https://www.youtube.com/watch?v=-4Yp3j_jk8Q)

------
kitd
For those who may have found the linked article difficult to read, here it is
neatly laid out (PDF):

[http://delivery.acm.org/10.1145/2740000/2736348/p38-lamport....](http://delivery.acm.org/10.1145/2740000/2736348/p38-lamport.pdf?ip=195.212.29.78&id=2736348&acc=OPEN&key=90259622823F2C32%2E97B4C8F68383D160%2E4D4702B0C3E38B35%2E6D218144511F3437&CFID=493697058&CFTOKEN=50811481&__acm__=1427704201_86137fab3766bc31f3fb4f1f24400798)

~~~
badpenny

      An error occurred while processing your request.
      
      Reference #50.cf633f17.1427707361.40a63048
    

Their error messages are as good as their typography.

~~~
virtualSatai
Try: [http://cacm.acm.org/magazines/2015/4/184705-who-builds-a-
hou...](http://cacm.acm.org/magazines/2015/4/184705-who-builds-a-house-
without-drawing-blueprints/pdf)

~~~
RyanMcGreal
Here's the HTML version:

[http://cacm.acm.org/magazines/2015/4/184705-who-builds-a-
hou...](http://cacm.acm.org/magazines/2015/4/184705-who-builds-a-house-
without-drawing-blueprints/fulltext)

------
fsloth
"Programmers spend a lot of time thinking about how to code, and many coding
methods have been proposed: test-driven development, agile programming, and so
on. But if the only sorting algorithm a programmer knows is bubble sort, no
such method will produce code that sorts in O(n log n) time. Nor will it turn
an overly complex conception of how a program should work into simple, easy to
maintain code."

This.

~~~
collyw
I wouldn't know a bubble sort off the top of my head (I haven't had to
implement anything like that since university). I would know to read up on
different algorithms and choose an appropriate library based on what I was
sorting. (It will probably be better tested than what I would come up with
first time).

------
ori_b
While I do think proofs and planning are both useful, I think that the analogy
doesn't work well.

The process of producing code is the process of specifying what the computer
should do -- the deliverable is the specification. On the other hand, few
civil engineers will start designing plumbing without at least having a sketch
of the floor plan and an idea of the building uses.

~~~
onion2k
_The process of producing code is the process of specifying what the computer
should do_

I'm sure coding is "specifying what the computer should do", but that's not
what people are talking about when they talk about specifications. A
specification defines what the _application_ should do. Producing code is
_implementing_ the specification. Without having any specification first you
wouldn't have a clue what the code needs to do, so you wouldn't know what to
write.

The problem with the analogy is that most people don't understand what a
blueprint actually is. A blueprint is an architectural planning document. It
defines the building in very broad terms - where the walls go, where there's a
staircase, and so on. It doesn't go in to the detail of _how_ the building is
constructed. That comes from all the other documentation. As an analogy with
software it's a pretty good one - a building's blueprint is equivalent to the
high-level planning documentation that any big project needs.

------
JoeAltmaier
Off topic: my house was built without blueprints. Talked to the contractor,
sketched what we wanted. He built it. Standing 25 years later, great job.

An experienced carpenter/contractor can build a house, without excruciating
detailed notes. In fact they can build it faster, adapting to conditions as
they change and solving problems efficiently.

------
herpelderp
Bees

~~~
lukesan
Yes, in an iterative way. Maybe it is also agile :)

~~~
Ygg2
Agile Swarm Manifesto?

------
fsloth
This so much to the point as well: "The math needed for most specifications is
quite simple: predicate logic and elementary set theory."

I would take ABNF as used in RFC:s and a few clarifying diagrams over verbose
UML vomit any day :)

------
pjmlp
Fully agree with Leslie, coding as you go is fine for single coder projects or
very small team with very talented developers.

For anything of scale we really need blueprints.

------
raverbashing
Same old waterfall crap?

Thanks but no thanks

~~~
pjmlp
I guess you prefer the agile with certified scrum masters crap instead.

~~~
raverbashing
Yes

I don't love it, but it works (better than the alternative)

And we don't have any more weird conversations about trying to get the entire
software, all the tasks, in one sitting.

~~~
pjmlp
Yeah, just weird conversations about when feature X is fully ready in which
sprint, features that were done getting new "improvements" and getting sprints
replanned in the middle of execution.

Oh, and the famous feature requests disguised as bug reports for the features
that didn't make it out of the backlog.

I have done both ways and still haven't found a way to getting it working
across the board with all parties.

~~~
raverbashing
It seems that those places are not taking Scrum seriously (as much as I hate
this expression)

> just weird conversations about when feature X is fully ready in which
> sprint,

What stories compose that feature? How are you going to plan the following
sprints? (are there other stories or only those?). Prioritize.

> features that were done getting new "improvements"

Yes, you can split stories into 2, or create a new story for something that
you want changed/improved. Create a story, put it through the system and do it

> and getting sprints replanned in the middle of execution.

It happens. But it shouldn't be frequent.

> Oh, and the famous feature requests disguised as bug reports for the
> features that didn't make it out of the backlog.

Well, that's not really an Agile problem, that's scope creep (and shouldn't be
allowed)

It seems your problems are due to people implementing "half agile" or just
using the buzzword without the important elements. Especially in small teams.

(been there, done that)

~~~
pjmlp
I could have replied to myself the same way you did.

My point is that I have never seen any company doing agile as their founders
created it.

Trying to push for agile way since 2006.

~~~
raverbashing
Ah yes, me neither (and I'm not interested in the nooks and crannies)

But there are some places that managed to "get it".

