I finally figured out the right analogy for software
development. Alas, the target audience for this analogy won't be happy
Why do we need an analogy? We know what we do. We program computers,
with all that entails. And we know what that means, because we do it.
But to the stakeholders -- managers, CEOs, customers, shareholders,
etc. -- software development is a mystery. They don't want to know
everything about it, but they want to know enough to be able to
predict the behavior of software development, at least approximately.
So stakeholders need an abstraction. An analogy. But for the analogy
to be useful, it needs to hide the things that aren't important, and
show the things that are. We've been flailing about with this problem
for a long time, but we've always been putting it in our terms,
and it all makes sense to us, so we can't differentiate between a
useful analogy and one that is less than helpful.
Mathematicians and engineers were the original programmers, so
naturally we tried making it a science, and then engineering. Mostly
we discovered that no matter how much we want software to be like
mathematical proofs or bridge-building, it isn't.
The stakeholders, trying to follow our analogies, asked questions that
were important to them. "If programming is like math, why are programs
always broken? Math is right or wrong, software is just broken." And
later, after we gave up on the science analogy, "If programmers are
like engineers, I should be able to replace one engineer with another
and get similar results, right?"
This latter has been a huge source of consternation among
stakeholders. By and large, engineers have similar productivity levels.
And the results produced are verifiable. There's a lot of
consistency in engineering, and if we call it "software engineering,"
then there should be similar consistency in software.
The two typical approaches to this problem have been either big denial
("ignore the differences and pretend all software development is the
same") or little denial ("The differences are accidental. We can
Big denial just doesn't work. But little denial has produced repeated
attempts at "standardization of software engineers," the most notable
of which is certification. If only we had a certification process, the
argument goes, then software engineers would be like real engineers,
and they'd all be consistent.
Fortunately certification has never gotten very far, because
programmers could never be bothered to take such a thing seriously,
and employers want to be able to hire the best programmers without
regard to whether they have any particular degrees or credentials. And
the certification programs that do exist are always done for money,
and that seems to inevitably flatten the curve. I don't know anyone,
for example, that takes the basic Sun Java Certification
seriously. The more advanced Java certifications seem more
interesting, but they also appear much more like workshops and less
like tests to me.
At one point I ridiculed this attempt to make all
programmers identical cogs in a machine by reducing our activity to
its simplest behavior in Programming as Typing.
So we're not scientists, and we're not engineers. How do we describe
what we do to non-programmers in a way that makes sense to them? In
particular, in a way that explains why there's such a big difference
in programmers, in programming projects, and in the success and failure
Here's my proposal. I think it explains everything. It will be very
unsatisfying to stakeholders that want completely predictable
behavior, and who want to replace one programmer with another and get
identical results. (That's still not going to happen. The only
compensation for the unpredictability is approaches like the
Agile methods, which increases the bandwidth of communication with the
Most people can put words together into sentences. They can
communicate adequately without being great writers. Most programmers
can write some kind of program. It probably won't be very good, but
most companies don't really need it to be very good. Most companies
only need basic programming skills. A college degree in computer
"science" from anywhere is good enough, and the job is just a job. It
doesn't require much in the way of continuing education, conferences,
workshops, or someone who is so interested in the craft of programming
that they are always trying to learn more.
Such people can write, but it's just basic writing. They are not
essayists or novelists -- and keep in mind that there are lots of
articles and novels that get published that are not particularly
well-written or worth reading. Obviously such things seem to sell well
enough to make the effort and risk worthwhile all around.
But someone who dedicates themselves to writing, who goes through the
struggle of figuring it all out and discovering their own place in the
world -- this is a very different kind of writer (of prose
or programs) than the average programmer. This person can
produce more functionality faster, and the results will be clearer and deeper than
Finishing a novel is a very impressive feat. Doing something that
might be worth publishing --
that's an even greater feat. But the vast majority of published novels
aren't worth reading. Only a small fraction of writers create
something really worthwhile, and no one, really, knows how they do
it. Each good novelist comes to their art in their own way. And what
about nonfiction? Every year there are about 5000 novels published, and about
50,000 nonfiction books. Most of those nonfiction books are merely functional, not
great reading. But they contain useful information and enough people buy them
to make it all worthwhile (to the publisher, at least).
This answers one of the biggest questions -- why you can't replace a
programmer with just any other programmer and get similar results. It
also suggests that you should evaluate what kind of project you're
creating when you decide who your team should be, and how it will
run. The creation of mysteries and young adult fiction and so-called
"bodice rippers" and the vast sea of nonfiction books
all have their own particular structure and
constraints (you'd be surprised at how rigid and controlling
publishers are about these things, as if they are manufacturing some
kind of basic commodity -- "the murder has to happen in the first 10
pages" etc.). None of these are the mass-market bestsellers ("killer
apps") that are sold by the author's voice and style (few of which
I find readable). The mass-market bestsellers usually don't
coincide with the great writers, since most people don't have the
patience to read these meta-craftsmen, just as most programmers don't
read the source code for compilers.
Although stakeholders won't necessarily understand the intricate
details of the writing and publishing process, they typically
understand that there are different types of writing, and that the
craft of writing is a weird, unfathomable and artistic process which
can't guarantee results. So even though "software is writing" is not
necessarily going to increase the predictability of what we do, it may
at least help non-programmers to understand its unpredictability.
My basic premise is that software development is writing for two audiences simultaniously, one human and one machine. And the fundamental difficulty of our dicipline is in creating abstractions that can be understood by both audiences.
As a first approximation, yes, programmers are like writers. But programming also involves functionality. So I'd say that writing software is like a combination of writing and inventing. Programming is not just art, not just science, not just engineering, but a combination of all of those things.
Novels and short stories and poems are like software for the brain. They entertain and evoke emotional responses. Unlike writing, software must perform a given task reliably and repeatably, ideally running without bugs. This introduces constraints. Compared to the writer, the programmer's vocabulary is limited, without ambiguity, but also without the nuance, tone, and feeling that the writer can employ.
Like architecture, programming is a craft with functionality constraints.
Another analogy is with the law (which also involves a lot of writing). A friend of mine who is a lawyer describes his craft as hacking society. Law is like code which runs on society, the corporations, government, and the courts. And compared to programming languages, OSes, and CPUs, these things are unreliable and buggy.
...now just sit back and wait for the inevitable retort that the reason we're not able to turn software development into a branch of engineering is that we're not trying hard enough, or because we need newer, more expensive toolchains, or any of the other standard responses whenever something like this is said.
My other favorite one is that it's like making buildings -- the architect designs perfect plans and then unskilled labor comes in to build the plans. Sadly, this analogy that only makes sense if you've never actually hired an architect and contractor to build anything.
Good writing can be taught. Good systems' development (programming, data, UI) can be taught. Just as the current financial meltdown has led to lots of finger pointing (that guy was an idiot) and no agreement on what the solution is, who should apply the solution, and have final authority; systems' development still can't (and by the nature of this post, doesn't want to) settle on the criteria for goodness. If we insist on the mantra that it's all unpredictable magic, in time nobody will believe us. Just as the recent finagled bank "profits" didn't pass scrutiny by those who know the game, our claim to magic will not be believed, either.
We can't even agree on something as significant as EJB (which one is best, or even works) or SOA (is it just CORBA redux doomed to fail, or is it windows 3.1, not nirvana but better than its predecessor and good enough).
What we don't have for systems' development is the equivalent of IWW; well, other than an Eckel seminar, of course.
I agree that we are writers, but rather than writing novels I think we are producing newspapers. The deadlines, the pressure to produce _something_ for that deadline, the skills involved in teasing out a story and perhaps making a story more interesting than it really is (even if only for ourselves).
To me it's a better description of how we have to work, and goes to the "functionnal reading" you mention. Also, I think the processes involved in putting out an edition of a newspaper are better understood than the process of putting out a novel.
Most of are writers writing for newspapers. Some of us work for the broadsheets, some of us work for the tabloids. Most of us dream of writing a novel.
I regularly use this analogy, but in a slightly different context.
I work at a university in an I-school... a new type of academic program that deals with information sciences, and is somewhat a cross between Computer Science, MIS, and Psychology, with a little bit of organizational behavior thrown in.
I'm surrounded by faculty and graduate students that are IT professionals and researchers, but cannot write a single line of code, some in fact going as far as disdaining the entire profession as beneath them.... something you can pay an undergraduate student $10/hour to do.
I'm trying very hard to change this impression of the profession of software development at my college. To that end, I'll often equate our field with that of writing. Sure, there are careers for folks to specialize in writing as an end to itself (literature, journalism, english, etc), but that doesn't excuse every researcher on the planet from having to write, and do so constantly and professionally.
If you're a researcher in the information sciences, or even a general IT professional, it behooves you to be able to string together a few lines of code occasionally, even if it's writing a simple script to process a dataset or a mathematical model in Matlab or Mathematica. And do so professionally, with attention to version control, unit testing, and documentation.
Writing software is indeed somewhat like writing prose in a proper human language. I say this as a somewhat successful published author of non-fiction and as someone with over a decade of experience both writing code and managing teams of developers. Now, one area where I have no experience whatsoever is special education. I am sure that mentally retarded children and adults are wonderful human beans in their own special ways. However, and please pardon me for being so non-PC, they have always seemed a bit limited to me. As have computers. I've often thought that my computer was a bit like the retard younger brother I never had, a trainable but high-maintenance, but nevertheless eager and useful moron. None too good at any real language, has to be talked to in very simple terms: the sorts of terms available in most computer languages. Perhaps it takes superior intelligence to get useful work out of something as stupid as a computer. Or a moron. And perhaps computer programming is like writing... for some severely retarded pieces of equipment.
Absolutely, this is right. I've been using this analogy for years actually as a way of trying to describe what I do.
Here's another perfect scenario that I run into that upper management just doesn't seem to "get" that totally fits the "writer" scenario: fragmented time.
Upper management (and even middle management -- made up of the guys who never could figure out how to write a good "novel" in Java or C++ or Ruby or...) looks at your week and they go: "Okay... you had x hours of meetings, y hours of predictable admin time (timesheets, etc.), and x - y = z hours left over which was nearly 20 hours out of a 40 hour week!! HOW COME YOU'RE BEHIND THE DEADLINE!!"
What they don't "get" is that "20 hours" was 1 hour and 2 hours there over the course of a week. You can't write a book that way and you can't write a novel that way. You most definitely have "plots" in software and "subplots" and characters that need to be developed JUST like in writing. And you can't do it 1 hour here and 2 hours there. It's definitely NOT like "math" or "engineering." It's MUCH more art than science. I've been saying this for years.
You can't give me 1 hour here and 2 hours there. I need longer spans of time to do the "development" (which THERE is a more appropriate word, but in software we don't take that word the same way we do in writing.) if you want a solid plot that will not fail and supporting subplots and good characters... I NEED DEVELOPMENT TIME!! LOTS OF IT (in span of time)!!
Explain painting in colored oils to a blind person. Explain poetry and ENGLISH to a mathematician. http://www.artima.com/weblogs/viewpost.jsp?thread=255898 title: Writing Software is Like ... Writing stakeholder viewpoint -- managers, CEOs, customers What is this mysterious 'software programming'? No, what are the Common Myths that are Wrong. Communication interace: programmer - encapsulation - pattern - abstraction stakeholder - framing - story - analogy 1.)There is a BIG difference between good writing and GREAT WRITING. Let there be light! - from bible. 2.)Everybody writes. Most people can put words together into sentences. Exceptional people can put words together into DOCUMENTS. 3.)Inspiration, Story and Meaning rise and fall of King Arthur and the Knights of the Roundtable It's the pattern, the pattern about the pattern and the meta-pattern. 4.)Simultaneous Chess Match, opponents are Supercomputer and Human. Against Supercomputer - logical AND non-intuitive AND non-creative Against Human Master - illogical AND intuitive AND creative 5.)Communication interface of Programmer and Stakeholder Agile methods important to understand unpredictability (both ways) 6.)Writing and Editing are like programming and testing programming intent is to build or create testing intent is to break or destroy
Are the greatest programmers 'rock stars'? No, wrong paradigm. Rock stars are intuitive and improvisational. Great programmers are Hollywood movie script writers. They extend the unusual methods of those special actor INTERACTIONS. The generation of extra-ordinary EDU-tainment is both art and science.
> I'm surrounded by faculty and graduate students that are > IT professionals and researchers, but cannot write a > single line of code (...)
Reminds me of a teaching assistant in university I knew (if I remember right he was teaching solid state physics). He had a problem with statments like "the demonstration of X is trivial". Whenever he heard something like this (it once happened while drinking beer in a pub, and ) he pretended to be stupid, and demanded to hear the demonstration. You could notice that students going to his seminars over at least a semester changed their attitude towards "trivial things".
Flat View: This topic has 54 replies
on 4 pages