PREVIOUS:

 

Judging books by the page

I confess I’m confused.

A good while back I read about the “page 69 test” — apparently descended to us from Marshall McLuhan. The idea is that you can open any book to page 69 and use that to determine whether you will like the book.

Well, OK. Page 69 of Dreaming in Code contains a description of Moore’s Law and concludes, “…there is no Moore’s Law for software. Chips may double in capacity every year or two; our brains don’t.” Whew. I think that’ll do the trick for at least some people.

Only next I read about a variation of this, called the “page 99 test,” and attributed to Ford Madox Ford: “0pen the book to page ninety-nine and read, and the quality of the whole will be revealed to you.” So, let’s see: on page 99 of my book you can read a story about how hard it is for developers to keep up with the tools available to them. In a visit to OSAF, a programmer named Anthony Baxter described his search for ways to speed up the processing of audio data in a Python application. Baxter was the release manager for the most recent version of Python, yet even he had forgotten that the programming language comes with a utility that exactly suited his needs. “The batteries were indeed included, as Python devotees liked to say. But with so many batteries, who could keep track of them all?”

OK. Fine. I’m willing to let my work be judged on this, too!

But now here comes the page 123 test! This one seems less about helping you decide whether to read a book and more about “bibliomancy,” or the art of making oracular use of arbitrarily selected passages of books. The page 123 test dictates that one “grab the nearest book, open to page 123, go down to the 5th sentence and type up the 3 following sentences.”

For Dreaming, this turns out to be a passage about the Chandler Project’s search for a development manager:

As the hunt dragged on, Lou Montulli and Aleks Totic suggested a name from their Netscape days. Michael Toy had been one of a band of employees at Silicon Graphics who left with its founder, Jim Clark, when Clark decided to start a new venture that would turn into Netscape. He had led the company’s programming team through several hyperspeed cycles of the browser wars in an era that redefined the norms for software development, establishing new benchmarks for fast releases of new versions.

I think I know what the multiplication of these memes is getting at. At this rate, authors are going to have to expect to be judged by every page they write. The nerve of that!

Books aren’t typically fractal — you can’t pull out lots of individual parts and allow each to stand for the whole. But each passage ought to count. In the end, every page and every sentence of a book ought to be able to present a good face for the larger entity it belongs to — like a diplomat abroad.


 

Code mining

I wrote Dreaming in Code because I believed that, as Bjarne Stroustrup says, “our civilization is built on software.” I noticed that creating software remains stubbornly difficult in certain ways, and, despite its centrality to our civilization, our understanding of that difficulty remains deficient. But I also wanted to create a journalistic record of the day-to-day experience of the software developer at the start of the 21st century — to tell a story about the act of programming itself.

I’m grateful that a good number of the book’s readers who’ve posted their thoughts feel that I achieved that goal. Others don’t think I did, and some days I agree with the criticism. Writing about the act of programming itself is as difficult as writing about any act of writing: the subject is an essentially interior process between the mind and the page (or screen), and it’s highly resistant to illumination.

Consider the difference when the topic of an essay is a rough physical act — like, say, digging coal out of the ground. I read a lot of George Orwell early in my career but I’d forgotten this passage, which Brad DeLong hoisted into the light of blog last year:

Our civilization, pace Chesterton, is founded on coal, more completely than one realizes until one stops to think about it. The machines that keep us alive, and the machines that make machines, are all directly or indirectly dependent upon coal. In the metabolism of the Western world the coal-miner is second in importance only to the man who ploughs the soil. He is a sort of caryatid upon whose shoulders nearly everything that is not grimy is supported. For this reason the actual process by which coal is extracted is well worth watching, if you get the chance and are willing to take the trouble.

When you go down a coal-mine it is important to try and get to the coal face when the ‘fillers’ are at work. This is not easy, because when the mine is working visitors are a nuisance and are not encouraged, but if you go at any other time, it is possible to come away with a totally wrong impression. On a Sunday, for instance, a mine seems almost peaceful. The time to go there is when the machines are roaring and the air is black with coal dust, and when you can actually see what the miners have to do. At those times the place is like hell, or at any rate like my own mental picture of hell. Most of the things one imagines in hell are if there — heat, noise, confusion, darkness, foul air, and, above all, unbearably cramped space. Everything except the fire, for there is no fire down there except the feeble beams of Davy lamps and electric torches which scarcely penetrate the clouds of coal dust.

It should go without saying that a wide gulf separates the strenuous and perilous experience of the “grimy” miners that Orwell depicted and the abstract, cerebral work of programming. The parallels are less obvious — but they jump out at me, too.

Both activities are essential to industry and highly profitable to those at the top of the economic pyramid they support. Both require the exploitation of long hours put in by young workers. In each, the treasures society values are struggled for in dim places and retrieved into the daylight after obscure labors to which their beneficiaries are oblivious.

Writing about a software project couldn’t have been more physically different from descending into a mine. But there were times, during my three years of research, when I felt like I was in an underground labyrinth, hunting for nuggets of insight in the dark.

It was, in any case, striking to find the “Our civilization is founded on…” construction that kicks off Dreaming in Code in Orwell’s penetrating lead. I’ve been trying to trace the Chesterton passage Orwell refers to as his antecedent, but so far no luck. Anyone have a clue?


 

Free Dreaming in Code paperbacks for bloggers

It’s been fantastic keeping track of the reviews and critiques of Dreaming in Code in the blogosphere for a whole year. I’ve diligently stored them by a Delicious tag, and fed them via that mechanism into a widget on the book Web site’s front page. Today there’s 275 URLs in that list.

To get the word out about the paperback release, I’ve gotten my publisher to donate some copies for me to hand out, here, free, to anyone with a blog who wants to read it. All I ask is that you post something about the book — positive, negative, indifferent, that’s up to you. Go ahead, tell me you think it sucks! Just write about why.

Yeah, one goal here is to promote the book. But I also wish to bow in the general blogospheric direction. I owe ye, bloggers, big time!

So: want a copy? Just drop me email at scottr /at/ this blog’s domain (or use the form, Luke). Send me your blog’s URL and your snailmail address so I can send you a book. I’ve got a bunch here. First come, first served, till they run out.

UPDATE: Sorry, the books are all gone…


 

Dreaming in paperback

This week, the paperback edition of Dreaming in Code arrives in stores. (And of course at Amazon, too.) The official publication date is Tuesday, Feb. 26 — tomorrow.

What’s the paperback like? It’s just like the hardcover — only the price is a bit lower, and there’s a new postscript bringing the Chandler story farther along. Pay a little less, get a little more. A deal, no?

In honor of this event, the next few days here are going to be a bit Dreaming in Code-focused.


 

OOPSLA podcast cornucopia

OOPSLA is the ACM conference that most broadly and widely addresses the sorts of questions I tried to explore in DREAMING IN CODE. I found the two events that I’ve attended, in 2004 and 2006, both highly rewarding. I couldn’t make the 2007 edition in Montreal, but I was delighted to find this page of podcast recordings of many of the conference’s highlights.

I’ve only had time to dip my toes in this stuff so far; there are talks by David Parnas, Fred Brooks, John McCarthy, Patti Maes, Guy Steele, Richard Gabriel, Gregor Kiczales and many others.


 

Spolsky: how programmers redefine their way around hard problems

I only just caught up with Joel Spolsky’s amusing and insightful Yale talk posted last December — a return-of-the-prodigal-son sort of thing for this Yale graduate. (Here’s parts one, two and three.)

These quotes were worth highlighting:

Time and time again, you’ll see programmers redefining problems so that they can be solved algorithmically. By redefining the problem, it often happens that they’re left with something that can be solved, but which is actually a trivial problem. They don’t solve the real problem, because that’s intractable.

This is a failing, in one sense — it’s why certain Big Problems in the field never seem to get solved. On the other hand, in the face of deadlines or business pressures, we can surely see the value in a programmer’s ability to take some problem that’s impossible to solve (given available resources) and redefine it as a job that can actually be accomplished.

And:

Being able to write clearly on technical topics is the difference between being a grunt individual contributor programmer and being a leader.

The hardest problems facing most programmers don’t involve communicating with the computer; they arise in the course of communicating with people — colleagues, customers, users.


 

A year of Dreaming in Code

I can’t believe that it’s been a whole year since my book came out (the official publication date was Jan. 16, 2007). The paperback will be out the third week in February, with a new afterword that carries the story through the release of Chandler’s Preview edition. The recent restructuring and cutbacks of the project are foreshadowed in this section. But they happened way past the time we could have added material, which is too bad — but I guess that’s one reason that I have a blog.

I’m proud to say that Dreaming in Code also recently went into its fifth hardcover printing. We did pretty well for a book about a Beckettian software project.

This is a good moment to thank Mark Bernstein for his warm review of the book, which posted over the holidays, so I caught up with it late. I’ve met Bernstein only a couple of times — many years ago at one of the Digital Storytelling Festivals in Colorado, and then once again at one of the Bloggercons. He’s a formidable innovator and leader in the field of serious hypertext fiction, and a software entrepreneur as well, both under the umbrella of his company Eastgate Systems. One of Eastgate’s products is a Mac-based PIM called Tinderbox, one of the very few programs I know of that fulfills at least a portion of the ambitions that Chandler set out with.

Anyway, here’s a bit from his post:

On this framework, Rosenberg hangs a masterful and engaging survey of the thinking that underlies contemporary software engineering. This overview will have lasting importance, as I think it’s destined be the textbook that introduces a generation of students throughout the world to the professional practice of software and to its founding voices — Brooks and the Mythical Man Month, Parnas, Joy, the postmoderns, the agilists.

He also offers some fair criticism:

What Rosenberg doesn’t capture — because Chandler seldom captured it — is the way software actually gets written: in slow, steady segments, in dashing sprints, in long nights of inspiration, in weeks of staring at the screen, but always — in the end — by one or two people working to get something to work. In practice, this usually means one or two people imagining how it might work, and then making it happen. There wasn’t enough of this in Chandler, and when it did happen, it too often happened to infrastructure, deep in foundations that were expected to underpin grand structures that were never built.

But concludes:

To have carved such a fine, generous, and useful book out of the debris [of Chandler] is a very fine accomplishment indeed.

I’m grateful for such a response. Bernstein has also posted some fascinating ideas on what he calls “NeoVictorian Computing,” which I keep intending to post on. Soon!
[tags]chandler, mark bernstein, tinderbox[/tags]