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 force consistency").

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 of projects?

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

We're writers.

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 ordinary code.

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.