On January 25th, 2013, Wired published an article by Leslie
Lamport describing the need to build software like we build houses. This wasn’t the first time I heard
this argument, but I was surprised that a publication as forward-thinking as
Wired would publish such a backwards-looking article. It absolutely doesn’t
make sense to build software like we build houses.
In his article, Lamport describes the need for
specifications to help software developers “think clearly about what we are
building.” Strangely, he seems to think that programmers don’t like thinking. In
my experience, programmers are proud to do work that is so cerebral, and they
enjoy opportunities to think deeply about their work. Another surprise is
Lamport’s conflation of thinking and specifying; the two are hardly one and the
same, and there are more ways to think than by writing specs. In general,
though, Lamport’s point is that software should have specs so that programmers
won’t make mistakes and software won’t be so hard to change.
Lamport’s overall argument is weak; he tries to make points
through metaphors more often than he does through logic. I won’t dwell on this,
though, as it’s been covered at length in the article’s comments. Instead I will point out what is implied by and missing from Lamport’s
apparent worldview.
Lamport's Worldview
Lamport seems to believe that making mistakes is a big problem
in software development and that writing specs is the best way to avoid it. This
thinking rests on the assumptions that the writer of the spec knows exactly
what the final state of the software should be – what it should do and how it
should do it. It assumes that requirements are fully understood, technology is
fully understood, and business conditions do not change. Over the past few
decades, the software industry has come to realize that this is not often the
case. I’m surprised that Lamport hasn’t
been made privy to this discovery, and I wonder whether the nature of
his own programming work at Microsoft Research has somehow shielded him from
it.
The software industry now understands fairly well that processes
with up-front investment in things that aren’t working software – things like
specs – work great for situations like accounting, cooking, and building
houses. Some people call these “defined process control models.” These
processes, while great in other industries, fall down on their faces when it
comes to software development, where we don’t often have a lot of certainty
about what we are building in, or how it will be built.
The Modern Worldview
In software we look instead to the empirical process control
model, which emphasizes inspecting and adapting (i.e., feedback loops) instead
of planning and then executing. This is what’s called for when we don’t know exactly
what our work product will ultimately look like or how it will work.
In empirical processes, instead of being asked to clearly
and unambiguously describe the exact output desired, a customer describes what
needs to be accomplished. Developers work in short iterations to incrementally
build what is needed, involving the customer all along the way, until the necessary
solution is discovered. The result of
these processes is typically better software.
Programming is Nothing Like Housebuilding
Building a house is arguably uncreative work. We can
categorize houses fairly simply based on their attributes and current state of
degradation. Houses, for all their variations, are largely the same and
generally serve the same purposes for anyone that lives in them.
Software development, on the other hand, is incredibly
creative work. The process of developing any two pieces of software will be
quite different, as will its ultimate outputs. Thinking one can accurately
define the exact output of a software development project is at best ignorant
and at worst arrogant.
We can’t know exactly what will be created at the beginning
of a software development project and that is okay. Instead we involve the
customer in the process so they can see exactly what is happening as we move
along. Lamport might call the evolution of the software in concert with
customer feedback a series of mistakes, but anyone who has developed software
this way knows there is actually incredible value in these iterations. Users
don’t need to visualize how the software will work because they can actually
use it after each iteration of development. And neither they nor developers
have to waste time investing in specs that will rapidly become obsolete.
And despite what Lamport said, well-built
software is incredibly easy to
change. Using techniques like TDD allow us to leverage the strengths of
software creation, and avoid the limitations inherent in the production of
physical objects.
