Wordyard

Hand-forged posts since 2002

Archives

About

Greatest hits

Ambiguity near and far

by

In Dreaming in Code I wrote a lot about the difference between ambiguity in programming, where it is often a source of trouble, and in “natural” languages (i.e., English or French or Mandarin), where it is often a source of value.

Jason Kottke points to this fascinating essay by Perl creator Larry Wall, in which Wall distinguished between “local” and “distant” ambiguities:

People thrive on ambiguity, as long as it is quickly resolved. Generally, within a natural language, ambiguity is resolved rapidly using recently spoken words and topics. Pronouns like “it” refer to things that are close by, syntactically speaking. Perl is full of little ambiguities that people never even notice because they’re resolved so rapidly. For instance, many terms and operators in Perl begin with identical characters. Perl resolves them based on whether it’s expecting to see a term or an operator, just as a person would. If you say 1 & 2, it knows that the & is a bitwise AND, but if you say &foo, it knows that you’re calling subroutine “foo”.

In contrast, many strongly typed languages have “distant” ambiguity. C++ is one of the worst in this respect, because you can look at a + b and have no idea at all what the + is doing, let alone where it’s defined. We send people to graduate school to learn to resolve distant ambiguities.

[tags]larry wall, perl, ambiguity, language, natural language, dreaming in code[/tags]

Apple and Brooks’s Law

by

Apple recently announced that it had to delay the release of the next version of Mac OS X, Leopard, by a few months — too many developers had to be tossed into the effort to get the new iPhone out the door by its June release. Commenting on the delay, Paul Kedrosky wrote, “Guess what? People apparently just rediscovered that writing software is hard.”

In researching Dreaming in Code, I spent years compiling examples of people making that rediscovery. I’m less obsessive about it these days, but stories like this one still cause a little alarm to ring in my brain. They tend to come in clumps: Recently, there was the Blackberry blackout, caused by a buggy software upgrade; or the Mars Global Surveyor, given up for lost in January, which, the LA Times recently reported, was doomed by a cascading failure started by a single bad command.

Kedrosky suggests the possibility of a Brooks’s Law-style problem on Apple’s hands, if the company has tried to speed up a late iPhone software schedule by redeploying legions of OS X developers onto the project. If that’s the case, then we’d likely see even further slippage from the iPhone project, which would then cause further delays for Leopard.

This is the sort of thing that always seemed to happen at Apple in the early and mid-’90s, and has rarely happened in Steve Jobs Era II. I write “rarely,” not “never,” because I recall this saga of “a Mythical Man Month disaster” on the Aperture team. If the tale is accurate, Apple threw 130 developers at a till-then-20-person team, with predictable painful results. We’ll maintain a Brooks’ Law Watch on Apple as the news continues to unfold.

UPDATE: Welcome, Daring Fireball and Reddit readers! And to respond to one consistent criticism: Sure, iPhone isn’t late yet, but Apple is explicitly saying it needed to add more developers to the project to meet its original deadline. If that all works out dandy, then the Brooks’s Law alarm will turn out to have been unwarranted. Most likely, given Apple’s discipline, the company will ship iPhone, with its software, when it says it will. What we won’t and can’t know is whether, and if so how much, the shipping product has been scaled back. And sure, of course this is all conjecture. Conjecture is what we have, given Apple’s locked-down secrecy.
[tags]apple, leopard, os x, software delays, brooks’s law[/tags]

Rick Kleffel interview, podcast

by

Rick Kleffel has a review site called the Agony Column, does a radio show for KUSP, and also podcasts, and sometimes contributes to NPR. So he keeps busy. I met him recently at KQED for an interview about Dreaming in Code, and he showed up with a copy of the book that bristled with more post-it-note bookmarks than I’d have thought physically possible:

Kleffel's encrusted Dreaming in Code

It’s great that Kleffel liked my book enough to pay it this kind of close attention. He also recognized my effort to find, in the saga of a software project, some broader themes: for instance, how strange and difficult it is for groups of people to work together creating anything that’s abstract. He wrote: “The book, though it stays focused on software engineering, is clearly applicable to every other realm of life.”

Here’s Kleffel’s review; here’s the audio of our interview. A version of it is scheduled for broadcast on KUSP on Friday at around 10 AM, if you’re in the general Santa Cruz vicinity.

Robots are hard, too

by

Friday’s Wall Street Journal included a book review of Almost Human: Making Robots Think,a new book by Lee Gutkind that’s a portrait of the work at Carnegie Mellon’s Robotics Institute.

That work, it seems, has its frustrations, and — as the reviewer, George Anders, tells it — the difficulties sound eerily like those recounted in Dreaming in Code’s description of the things that make software hard:

Mr. Gutkind’s second big insight involves Carnegie-Mellon’s approach to project management. It’s awful. Goals aren’t defined. Interim deadlines aren’t met. Crucial subsystems turn out to be incompatible. People rely on all-nighters to get everything finished. Such bad habits invite catastrophic blunders by exhausted people whose last-minute “fixes” snarl everything else.

In the most maddening breakdown of all, the scientists devising research projects seldom communicate well with the engineers trying to build them. Even the word “target” becomes a sore spot. To scientists, it means their working hypothesis. To engineers, it means the robot’s physical destination. Unaware of this gap, supposed colleagues get mired in confusing conversations.

Gutkind’s book is now on my “must read” list. One final irony to me, coming out of Dreaming in Code, is that Carnegie Mellon is not only home to Gutkind’s roboticists; it also harbors the Software Engineering Institute, which is ground zero for the CMM, CMMI, TSP and other acronymic attempts to add a framework of engineering rigor around the maddeningly difficult enterprise of producing new software. I might be jumping the gun (not having read Gutkind’s book yet), but it sounds like those roboticists and the SEI people should have lunch some time.

Open endings

by

One of the more common criticisms of Dreaming in Code is that some people are disappointed the book ends without a clear resolution to the Chandler story (which was still unfolding at the beginning of 2006, as I wrapped up my work on the book, and is still unfolding today). So my ears perked up last week as I listened to NPR’s Weekend Edition and heard its film critic, Elvis Mitchell, defending the David Fincher movie Zodiac (which I haven’t seen and have no opinion about) from Scott Simon’s complaint that it lacked a satisfying wrap-up. Mitchell argued that the whole movie is an homage to the ’70s indie-film aesthetic and that a willingness to tell stories without providing a traditional ends-tying conclusion was a hallmark of that era’s directors.

Here’s the passage:

SIMON: The film doesn’t tie anything together with a pretty — or in this case, since you’re talking about a murder, an ugly — series of bows. I know it’s real life, I know there was no way of avoiding it; but I found tht dramatically unsatisfying — to go through this long movie, and not have that at the end.

MITCHELL: It’s so funny you say that, Scott, because that’s a ’70s movie ethic — they’d say, basically, you can’t say that things are tied up anymore, these aren’t John Wayne movies, these aren’t Jimmy Stewart movies, these aren’t Henry Fonda movies. The real act of creative bravery in Zodiac is to follow with that, and to say that this is what these movies were, these movies that influenced me as a filmmaker, and I’m going to use that here, in a case where people really want that kind of closure, and not give it to them.

I can’t claim that my choice to conclude Dreaming in Code the way I did was any sort of statement of allegiance to authors or auteurs past. More, it was just a belief that, in non-fiction, you’d better let the shape of the story be dictated by reality and not wishful thinking.

A palpable hit

by

I am proud to announce that Dreaming in Code is now in its third printing.

No, it’s not on any bestseller lists. (That I know of!) As a hit, it is of the slow-burn kind. But it’s selling well enough to give me a gentle feeling of vindication towards those observers who, at various stages of the project, doubted that a detailed chronicle of a software project with no world-changing heroic outcome or billion-dollar payoff could attract many more readers than you could count on the fingers of one RSI-addled hand.

Like any introspective and at least marginally neurotic writer, I of course had a voice in my own head saying similar things. So it gives me some calm satisfaction to note the book’s success and to continue to read the generous flow of comments, kudos and criticisms flowing back at me from the blogosphere and the media.

In recent coverage, Glenn Fleishman (in the Seattle Times) said that — since I ended up “adrift with an intrepid crew, a host of dogs and an ample food supply” yet found that “After three years, no land was in sight” — I should be humming the Gilligan’s Island theme. (Okay, but only in one of the punk cover versions!)

In the Chicago Tribune, Mark Coatney said that “Rosenberg clearly knows what he’s talking about and knows how to tell a story.”

Still, my favorite pro-media review to date appeared in the Irish Times (alas, behind a pay wall) — perhaps because, despite the mainstream venue, the author is the estimable geekographer Danny O’Brien, creator of the NTK newsletter, progenitor of the Life Hacks movement and (I think) currently a staffer at the EFF. Here’s a bit of the review:

Books like Rosenberg’s do a great job at allowing us to step away from the keyboard and see our foibles as others might see them. His skill in portrayal lies not just in explaining the tribulations of the software project to the layman, it also lies in explaining them afresh to the seasoned — and therefore oblivious — hacker.

His mastery in picking just the right metaphor to pull an obscure coding controversy into the common world is unparalleled: I’ve never seen the difference between software’s “back-end” and “front-end” portrayed better than in Rosenberg’s analogy between the incomprehensible R2D2 and its fey, deferential interpreter, C3PO.

But even more impressive (at least, to me) is his ability to uncover anecdotes and connections that even the most oversurfing geek would not have heard. Even for me, an obsessive follower of the trivia of tech culture, there were genuine surprises in every chapter…

…It’s perhaps forgivable that such great literature on programming should happen so rarely: the mix of tech skills, explanatory abilities, and sheer determination to trail and document what from the outside looks as exciting as an accountant’s meditation retreat, is rare among writers of Rosenberg’s calibre. But we badly need those books to be written.

Dreaming in Code on KQED Forum, Tuesday

by

I should be on KQED Forum tomorrow (Tuesday) at 10 AM Pacific time, if all goes as planned, talking about Dreaming in Code. Tune in — or call in!

I’ve now concluded my two week stint in the Well’s Inkwell conference — a slow-motion interview about the book that goes a little deeper in various ways than some of the other conversations I’ve had about the book. (Unlike most stuff on the Well, this is “world-readable” — no membership required.)

Leaking entities

by

Today’s software is built up in layers, like sedimentary rock that has been accumulating over many generations. In Dreaming in Code I wrote about how sometimes the lower layers poke up through the surface, like angled strata of rock, disturbing the placid interface surface. (This was merely a metaphoric restatement of Joel Spolsky’s Law of Leaky Abstractions.)

Examples of this are all over the place. This morning, for instance, I went to have a look at the new beta of My Yahoo (here’s the TechCrunch report). And here’s what I saw at the top of the page:

Notice the center button. This is, of course, an HTML code or “entity” representing the “non-breaking space”, and it is rearing its ugly little head onto the shiny new AJAX-y fresh My Yahoo screen.

Presumably some designer or developer entered that data long ago, maybe long before anyone ever thought it would end up labeling a button in this environment. Or maybe it was coded consciously that way with the expectation that the HTML data, including the non-breaking space code, would be transformed by the My Yahoo application in such a way that each layer would understand that it was looking at an HTML entity and handle it properly. However it happened, the bug exposes a layer of the software you were never supposed to see.

It’s a tiny bug, to be sure, on the first day of a public beta. It will probably be gone soon. But such “entity” codes have made their way often enough over the years onto Salon’s home page — so I find it a little reassuring that these things happen even to the experienced and well-staffed team at Yahoo.

CyberSalon notes

by

Last night’s Berkeley CyberSalon panel was great fun — thanks to Eric Allman, Chad Dickerson, Lisa Dusseault and Jaron Lanier for sharing their thoughts, and to everyone else who showed up with their time, their questions and their trenchant comments. (I had not known that both Jaron and Lisa have very recently become parents, and if I had I might not have presumed to ask them on the panel, but I’m very glad I did, and grateful that they put aside their parental duties long enough to participate.)

One of many highlights for me was the moment when Eric hauled some old inch-thick booklets out of his briefcase — one contained the entire set of Internet (then Arpanet) protocols from the late ’70s, bound in a mere single volume; the other was a complete list of the network’s users. My, things have changed.

There’s a downloadable podcast/MP3 file of the whole event if you’re curious.

Code Reads #8: The Cathedral and the Bazaar

by

Code ReadsThis is the eighth edition of Code Reads, a series of discussions of some of the central essays, documents and texts in the history of software. You can go straight to the comments and post something if you like. Here’s the full Code Reads archive.

The Cathedral and the Bazaar, Eric Raymond’s classic essay on open-source software development, is now 10 years old. I first read it soon after its publication. At that time the term “open source” was newly minted, and the movement was in the news chiefly because (a) it seemed to offer a threat to Microsoft, and (b) Netscape, at a late stage of its war with Microsoft, had decided to release its browser code under open-source license. I was editing Salon’s technology section in those days, and one of our central projects was Andrew Leonard’s thorough coverage of the open-source phenomenon. (He interviewed Raymond in early 1998.)

I think it’s fair to say that today CatB (as Raymond and others now call the essay) has proved its importance independent of its place in the long-concluded browser-war saga. I’ve reread it several times over the years since, and each time find something new and valuable.

[Read more…]