Wordyard

Hand-forged posts since 2002

Archives

About

Greatest hits

An interview and a profile

by

A few weeks ago I had the pleasure of being interviewed by Ed Cone about Dreaming in Code. I first met Cone years ago when he was organizing the panel I spoke on at the first BloggerCon. I’ve always enjoyed his work; like me, he’s someone who is equally interested in politics and technology, and blogs about both of them.

The Cone interview is now up at CIO Insight. It was fun to talk about the issues in the book for a relatively expert readership, where I could skip over some of the basics and jump right to the harder questions. Cone did a great job of drawing me out and then trimming the verbal excess from my responses.

CIO Insight: Are we just being impatient with a branch of knowledge that is still fairly new? Or is there something inherent to software development that makes it so weird and vexing?

Rosenberg: You get one perspective that says, hey, we now have a computer on every desk that does things that were unimaginable 20 years ago, and they’re all connected in this network that gives us instant answers and instant connections. These are miraculous things. And then you find other people who say, you know what? We’re still writing code basically by picking out characters one at a time, we still have programs that are laid low when a single bug creeps in, we still have projects that take ten times longer than they should, we need to rethink everything from the ground up.

I don’t have an answer between them. My personal temperament is more towards the optimistic. In the end, what you’ve got is this industry that’s been conditioned by Moore’s Law, and by its own fantastic financial success, to assume that the curve is always an upward curve, that everything gets better at an exponential pace. That’s the experience of the technology industry. You have that smacking up against the reality of human experience, of creativity, of people working in teams. We have these basic human factors, psychology, the limits of the conceptual capacity of the human brain—things that do not move at an exponential pace. They simply don’t. They tend to move linearly, if they are improving at all. People in the technology industry are loath to accept that.

This theme is also at the heart of another piece that occupied me for a considerable part of the fall — a profile of Charles Simonyi that is on the cover of the new issue of Technology Review. I covered Simonyi and his Intentional Software project just a little bit in Dreaming in Code, and I’m grateful to Jason Pontin at TR for giving me the chance to look at him, and it, more fully.

The first part of the profile, “Anything You Can Do, I Can Do Meta,” is up at the TR Web site now; the second part is slated to go up tomorrow. Since the piece was written as one integral whole, you might want to wait till you can read it all at once — I’ll post the link. It was fun to be writing for print again, and Technology Review is looking very spiffy these days, so this is one that you just might be better off reading on paper.
[tags]charles simonyi, ed cone, technology review[/tags]

Can you send a file to the Internet?

by

I’ve always thought of the Internet not as a place but as a means of connecting other entities — sites, servers, people, etc. (Hey, in that sense maybe it is “a series of tubes”!) From its beginning in the antediluvian mists as what was known as a “network of networks,” connecting pre-existing but now-forgotten networks with a common set of protocols, the Internet was not a destination but a means of transport between other destinations.

So for me, the phrase “on the Internet” isn’t ideal, but it makes some sense as shorthand meaning “on one of those other things that is on the Internet.” But recently I’ve noticed a couple of usages that caused me to stop short. Both were in the New York Times, and from writers who are as or more steeped in Net lore than I am.

In an otherwise highly useful recent roundup of backup services, David Pogue refers to “online backups, where files are shuttled off to the Internet for safekeeping.”

Files “shuttled off to the Internet”? I can picture files that are shuttled across the Internet, to some server or disk array or whatever. But what happens to a file that’s sent to the Internet? I get this picture from the old Star Trek episode in which Captain Kirk took a trip through the transporter and didn’t come out the other side; his molecules got scrambled in interstellar space. If I send my file “to the Internet,” I’d really worry about those bits just sort of dissolving into the void.

Similarly, John Markoff’s fascinating piece on botnets from Sunday’s Times, Attack of the Zombie Computers is a Growing Threat, begins with this sentence: “In their persistent quest to breach the Internet’s defenses, the bad guys are honing their weapons and increasing their firepower.”

Does the Internet have any “defenses” at all? Individual Web sites and corporate networks and ISPs do, of course, and they are all scrambling to deal with the torrent of spam being produced by these bot-infected zombie computers.

In a sense, I suppose the Internet has structural defenses, in the form of the relative security of the protocols and conventions users rely on (like encryption), and social defenses, in the form of the people who work hard to stymie the stuff that bad actors do. But these are not really “the Internet’s defenses”; they’re things that people do to defend their Internet-connected computers.

This probably sounds like nitpicking, but I think there’s something at stake in how English usage shapes how we think about the Net.

The great thing about the Internet is that — unlike its “walled-garden” predecessors — it is not a single place with one set of “defenses.” In the memorable words of the “World of Ends” manifesto by Doc Searls and David Weinberger, “No one owns it; everyone can use it; anyone can improve it.” (And, as the botnets show, anyone can try to wreck it, too.) When it comes to descriptions of the Internet, I am instinctively biased towards language that embodies these principles, and my brain registers a little squawk of concern when it encounters phrases that don’t.
[tags]world of ends, language, usage, internet, john markoff, david pogue[/tags]

First responses to Dreaming in Code

by

I spent many, many years writing reviews — of plays, movies and books. Over the next few weeks, it’s my turn to be on the receiving end. I have vowed to savor the praise, to engage with the honest feedback, and to avoid tiresome quarrels with any pans. Hold me to that if I slip, okay?

I got some warm advance comments from Joel Spolsky earlier this week, and that was cool — since Joel’s reliably entertaining commentary was one of the factors that persuaded me it’s possible to write about programming without putting readers to sleep. Today marked my first mainstream review, in BusinessWeek. They liked the book, calling it “a fascinating look inside one software-development project” and saying that I “know my subject” and “its scenes are vivid.” I’m grateful for the praise.

BusinessWeek also said that it was “frustrating” that, at the end of the book, Chandler still isn’t done: “Under deadline pressure from his publisher, [Rosenberg] sat down to write the book even though the project had not been completed.”

In fact, the decision to wrap up when we did was mine. No one at Crown, my publisher, pressured me. No publisher wants to wait forever for a manuscript, I guess. But I’m sure if I’d gone to Crown and said, “It will be a better book if we wait another six months,” they’d have approved.

If it had looked like the product was going to be complete (or reach some critical milestone) in only a few more months, I’d have just pushed back my writing schedule. But at the end of 2005, which is where the book’s saga leaves off, there was still no way to predict when the Chandler story would end.

More important, I felt that I’d already unearthed more answers to the questions I’d set out with — why is making software so hard? why does it take so long? what can we learn by observing the intricacies of a real-world project? — than I could possibly fit in one book.

One of the themes at the heart of Dreaming in Code is the strange nature of what I call “software time.” Working on software often means entering a sort of twilight zone in which the normal timeline of the calendar becomes a bottomless black hole.

If the Chandler story had provided a slam-bang finale, that’s how I’d have ended the book. Instead I tried to give Dreaming in Code a conclusion that’s peculiarly true to the material, in a way that I hope readers will find pleasing.

At book’s end, the Chandler team was just beginning to use their own program in “dogfood” fashion. I’ll be posting more soon about what’s happened with Chandler since that point; 2006 saw considerable further development, with a new focus on a “ship-it mindset,” and a fully usable “preview” edition is now scheduled for an April 2007 release. (Katie Parlante, one of the Chandler team’s key managers, has posted an update over at the OSAF blog with more details.)
[tags]osaf, chandler, book reviews, dreaming in code, businessweek, joel spolsky[/tags]

Code Reads #7: Parnas’s “Star Wars” paper

by

Code ReadsThis is the seventh edition of Code Reads, an aspiring-to-weekly discussion 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.

In the early 1980s, president Ronald Reagan proposed the missile-defense program known formally as the Strategic Defense Initiative (SDI) — and informally as “Star Wars.” Then the Pentagon and its contractors began trying to build the thing. They’re still at it today.

In 1985, David Lorge Parnas — a well-reputed computer scientist best known for elucidating the principle of “information hiding” that underlies modern object-oriented techniques — publicly resigned from a government computing panel that had been convened to advise the Star Wars effort. Star Wars couldn’t be built according to the government’s requirements, Parnas declared, because the software simply couldn’t be built. Unlike many who weighed in on Star Wars, Parnas didn’t express opposition on moral or political grounds; he was, he said, a longtime toiler in the field of defense software engineering, and had no “political or policy judgments” to offer. He just thought that SDI’s engineering aspirations lay impossibly far outside the bounds of real-world capabilities.

In support of this judgment Parnas composed a series of eight short essays that the American Scientist — and later the Communications of the ACM — published together under the title, “Software Aspects of Strategic Defense Systems.” It’s a magnificently forthright piece of writing — it encapsulates the best of the engineering mindset in prose. And it explains some fairly complicated notions in terms anyone can follow.

For instance, it wasn’t until I read Parnas’s paper that I fully understood why digital systems are so much harder to prove reliable than analog ones. [Read more…]

Office 2007: An iconoclastic view

by

The infuriating aspects of Microsoft Word are legion, and whenever possible I prefer to write in a plain-text processor. But sometimes you have no choice but to work in Word, scratching your head over its stubborn peculiarities and gradually, over the years, acclimating yourself to its interface.

Now, as Walt Mossberg details in his column today, Microsoft is about to throw out years of tradition in Word and the rest of Office. In the new Office 2007, it seems, there are no menus. That’s right — the basic tool for controlling the screen since the early days of the Macintosh is gone, replaced by a newfangled, multifaceted toolbar called the Ribbon.

Mossberg gives it a mixed review (though he admits to “cursing it for weeks”). No doubt Microsoft has invested millions in testing it. I haven’t used it at all yet, so I could be off-base. But thinking about this change, or even just looking at the screenshots, makes my head hurt.

Maybe I’m unusual, but I have always found the dizzying array of toolbar icons in Office programs profoundly unhelpful. Icons are fine when they are small in number and used constantly (think of the stop, reload, back and forward buttons on your browser). But when you have a multitude of complex tools and features, as in Word, you never really get the hang of what all those little hierogylphs really mean. Either you wait for the “tooltip” to pop up (but why should the text have ever been relegated to this second layer?) or you go to the menu, where at least the function will be represented by an English description that has some relationship to what it does.

From now on, sorry — no more menus. Maybe there’s an option to flip the Ribbon to text descriptions, but from Mossberg’s description, it sounds like this Office is less customizable, not more, than the old one. The keyboard commands that heavy users rely on for common operations apparently are unchanged, so that’s nice. But when you need to find that odd command you only use once a year, good luck rummaging through trays of icons.

POSTSCRIPT: Harvey Motulsky writes to tell me that most of the Ribbon toolbars (though not the very first one, apparently) do have text labels on them. He points me to Jensen Harris’s blog at Microsoft which records the process of the redesign — I’ll look forward to reading that later. And, in comments, Walt Mossberg suggests I’m just showing my stripes as an “old-fashioned reporter” — no doubt guilty as charged.
[tags]microsoft, office 2007, walt mossberg, interface design[/tags]

Building a book site with WordPress

by

It probably says something about me that, after completing years of work on my book, one of the things I most looked forward to was…building the Web site for the book. Aside from my work at Salon and my launching of various blogs, it had been years since I built a Web site on my own, and I relished the chance to look around at all the new tools for content management that have emerged in the interim.

But pretty quickly I realized that learning any new tool takes time, and I didn’t have a lot of time. And then I also realized that I’d spent a lot of time last summer learning to use WordPress as the new platform for my blog, and there was no reason under the sun I couldn’t use WordPress to build the book site for Dreaming in Code. WordPress lets you publish static pages; all I had to do was customize some templates, and voila! — blog software without the blog.

I am, as I admit at the start of Dreaming in Code, barely a programmer myself. But I can find my way around a template, I can borrow snippets of code and mess with a system that already works just enough to get it to do what I need it to do. This approach was, once upon a time, called “end-user programming”: the idea of enabling sophisticated users to extend and adapt a powerful piece of software without their needing to master complex programming languages. Spreadsheets depend on end-user programming; back in its day, Hypercard did, too. (Bonnie Nardi’s 1993 book A Small Matter of Programming is a good outline of the concept, focusing on spreadsheets and CAD systems.) A good blogging tool like WordPress is an invitation to end-user programming. And I admit it: I had fun!

The part that wasn’t fun was wrestling with CSS. I know that CSS achieved a Good Thing in helping Web designers clean up HTML and separate content from presentation and all that. But making a Web site look exactly the way you want it to look was a hell of a lot easier back in the days of tables and simple HTML than it is today. There are still a few elements of my site that aren’t aligned exactly the way I want them; I gave up trying to figure out why — life is too short! CSS was a step forward for designers’ control of their Web work but a step backward for the end-user programming that made the Web what it is today.

In Baghdad as in the Beltway, leakers must be punished

by

The hanging of Saddam Hussein proceeded more like an act of sectarian vengeance than an orderly process of law, with guards chanting “Moktada! Moktada!”, heralding the name of the militia leader who backs the current Iraqi president — and whose forces the forthcoming U.S. “surge” will attempt to disband.

The only way we know this is because of the leak of a cameraphone recording of the clandestine event.

So what does the Iraqi government do? Arrest the guy accused of taking the pictures! (Who may well be a fall guy for the Iraqi national security adviser, anyway — see Josh Marshall’s parsing of the evidence.)

In this, the Baghdad government is simply taking cues from its American sponsor, the Bush administration — which has always treated the release of embarrassing information as an opportunity not to right the wrong but rather to shoot the messenger and crack down on leaks. As one correspondent over at Talking Points Memo argues, the Maliki government’s high-handed contempt for the legal process mirrors that of the American administration that brought it into being.

But I think the key to understanding this strange saga lies in how differently the video plays to different crowds. If you’re Prime Minister Maliki and your power-base and lifelong allegiance is to the Shiite side, you might figure that a record of the final humiliation of the oppressor Saddam would be a valuable bit of propaganda to show your people. You might not mind a little leak; you might even encourage your officials to record the proceedings. But the proceedings get a little more unruly and uglier than you expected — and suddenly the images that your in-country partisans savor are turning stomachs around the world (and driving the last remaining moderate Sunnis into the insurgent camp). So you disavow any responsibility and find some low-level scapegoat to blame.

A couple of days ago it was hard to imagine how the fallout from the botched Saddam Hussein execution could get any worse. But Maliki and his crew keep pushing the envelope.
[tags]saddam hussein, iraq, leaks[/tags]

Code Reads update and schedule

by

I’m sorry that I wasn’t able to keep up a rigorous weekly schedule for Code Reads through the fall — too many conflicting demands. I’m getting serious now, though, and setting some dates down here. (Public commitments to deadlines always concentrate the mind.)

January will be something of an all-star month full of well-known classics in the field, in honor of the forthcoming publication of Dreaming in Code.

Later this week I’ll be posting the next Code Reads installment on David Parnas’s “Software Aspects of Strategic Defense Systems,” his 1985 essay about the Reagan-era Star Wars program, and why its software needs would doom it.

Next week (Jan. 8), we’ll look at Eric Raymond’s manifesto, The Cathedral and the Bazaar. Sure, you’ve heard of it, you know all about it — but when’s the last time you actually read it?

Then, the following week (Jan. 15), to mark the official launch of Dreaming in Code, we’ll take a look at the essay that I view as, if not the cornerstone of the entire field of software development, then certainly the distillation of the questions my book centers on: Frederick Brooks’ “No Silver Bullet.” We touched on some of the issues back when we started with “The Mythical Man-Month,” but “No Silver Bullet” spins quite a separate argument that’s worth grappling with on its own.
[tags]code reads, no silver bullet, david parnas, cathedral and bazaar, eric raymond[/tags]

Surge and destroy: Bush’s escalation folly

by

Let’s consider the coming escalation of the war in Iraq. Most reports from inside that strange Green Zone known as the Beltway suggest that President Bush, having heard the electorate’s verdict last November and having reviewed the many recommendations of the Baker commission he appointed, is going to ignore them all — and instead send 20,000 to 40,000 more American troops to Iraq. This escalation has been officially dubbed “the surge,” since that noun implies a comforting temporary quality to the escalation, like a wave that will wash forward only to roll back at some near-future date.

During the long months of 2004 and 2005, as the situation in Iraq deteriorated and the Bush team tried to keep up appearances, the White House brushed aside all suggestions that we might need to reinforce our contingent in Iraq. Before the invasion, Secretary of Defense Donald Rumsfeld essentially cashiered General Eric Shinseki for daring to suggest that the occupation would require twice as many troops as the SecDef was deploying. Having brought the military brass to heel, the White House then insisted that, in not bolstering the Iraq force, it was only doing exactly what the generals wanted! Responsibility-shirking kabuki has rarely been performed with such bravura skill.

Still, today I think most Americans outside the Beltway understand what’s happened: When additional troops might have made a difference, Bush wouldn’t supply them. Now, when the generals are saying we can’t possibly support an escalated commitment, Bush is saying, send in the surge!

My first impulse here is to tear my hair out. My second is to think back to Richard Nixon’s ill-fated invasion of Cambodia — a similar “double-down” gamble late in a losing war, in a vain effort to “change the dynamic” and “get at the root of the problem.” No “surge” in Iraq is likely to have any more long-term value than Nixon’s folly. But like that antecedent — which destabilized Cambodia’s government, opening the door to the Khmer Rouge and its genocidal horrors — this escalation is quite likely to cause havoc in ways we can’t even imagine today.

Today’s Wall Street Journal details one likely area of collateral damage from a surge: Some Pentagon leaders seem to feel that it could “break the force,” pushing the overstretched U.S. military to the snapping point. The only way to make the “surge” happen is, essentially, to borrow against the future — to deploy forces now that might have been the replacements for U.S. forces in Iraq a year or two in the future. Field them today and there’s less for tomorrow. (If this carries echoes of the Bush administration’s “Cut taxes now, make our kids pay” economic policy, well, what a surprise!)

Senior military commanders believe the extra forces can be sustained in Iraq for only six to 12 months before logistical and manpower strains become untenable. Gen. Peter Schoomaker, the Army’s chief of staff, has told associates that 12 months is needed to ensure a substantive effect.
Echoing Gen. Schoomaker’s concerns that Iraq’s militias would simply wait out a three- or six-month surge and then resume their violence, a report by military historian Frederick Kagan argues that the troops should be in Iraq for at least 18 months. The U.S. has about 140,000 troops in Iraq, and the additional forces could total as many as 20,000.

It’s hard to know what’s more ludicrous: the idea that boosting U.S. forces by roughly 15 percent could change the hopeless dynamic in Iraq at this late date; the desperation of the Bush administration’s ever-deeper retreat from reality; or the pretzel-logic calculations necessary to dress up the “surge” in the trappings of a reasonable policy: “Well, men, we can only keep the extra troops for 6 to 12 months, but we need them for 12 to 18 months, so I guess it’s a one-year deployment, and cross your fingers that the job gets done!”

But what job, exactly? Tame the Shiite militias? That would mean dismantling the democratically elected government of Iraq, which just happens to be led by a die-hard partisan of one side in an increasingly murderous civil war. “Restore order”? How, exactly?

The time is long past when we might rationally expect to achieve any goal in Iraq other than getting our troops out safely. Even that is looking less certain. Today, we’re throwing more troops at the problem without defining the problem. What is the mission of the “surge” reinforcements? Is there a “success condition”? And when, a year from now — just as the Bush administration today is admitting that last year’s war plan was a bust — we admit that the “surge” was a failure, how do we scale back? Is it even possible, given the chaos in Iraq today, for U.S. forces to accomplish a gradual, orderly withdrawal? When we’re down to the last brigade, how do we stop the retreat from turning into a rout?

These are the sorts of questions the Bush administration ought to be asking itself today, and trying to answer now. If it waits to ask them till a year from now, it will end up with even more blood on its hands.
[tags]bush administration, iraq, surge[/tags]

The “invention” of RSS and the snowball effect

by

The arguments over the history of RSS are interminable and overheated, and I wouldn’t fault anyone for tuning them out. RSS is the technology (really, that’s a glorified label for what is a relatively simple file-format specification) that lets you subscribe to feeds from blogs and other Web publishers. Early adopters on the Net have embraced RSS whole hog; today it’s how I take in most of the information I read online. Yet much of the general public is still awaiting a basic introduction to this incredibly useful tool. Back in 2003 I wrote that, with RSS, it felt like we were about where we were in 1994 with the Web itself; today we’re maybe in 1996 or 1997.

RSS is important, and so technology industry leaders and pundits have already devoted a remarkable amount of energy toward arguing about its origins — including, most recently, debating a controversial patent filing by Microsoft. (The idea of patenting anything to do with RSS strikes me as ridiculous and counter-productive, but my grasp of patents is limited, and it’s always been hard for me to understand the idea of any kind of software patent.)

Even if you’ve tuned out the RSS debate, though, I’d recommend checking out Dave Winer’s post from today, “RSS Wasn’t Invented.” Dave argues that what matters in the RSS story isn’t the (non-existent) moment that the idea for the technology was conceived, but rather the complex and slowly-unfolding process by which RSS tools came into wide use. Discovery of the value and purpose of RSS, you might say, took place long after the specifics of its technical functionality were first imagined.

The “invention” of RSS, muddied as it was by prior art, wasn’t responsible for its uptake. Rather there were several significant moments along the way: support by individual publications, individual bloggers, then blogging tools, then a small number of aggregators and readers, then a few very large publishers, then a flood of publishing and reading tools, followed by a flood of content.

I can vouch for Winer’s argument because I recall the early adoption of RSS at Salon, in, I believe, late 1999 or early 2000. We needed a simple tool to circulate our daily list of headlines and links to partner sites, and one of our engineers chose an XML file format he was familiar with through its use by Netscape. We didn’t know it by the name “RSS,” and we weren’t adopting it for any purpose relating to blogging. We just grabbed a handy format that looked easy for our partners to receive and put it to use. Later on, the rise of blogs — based on publishing tools that Winer, and the folks at Blogger, and later the folks at Movable Type and others, had produced — created a demand from the general public for subscribable RSS feeds. When I went to our engineering team and said, “We need to provide an RSS feed for Salon,” we realized that we had one already, we just weren’t calling it that.

RSS was simple for developers to produce and gradually got easier for non-technical users to consume. The complex and murky (and contentious) story of how its technical specifics gradually coalesced is far less important than the social process by which a “virtuous circle” or snowball effect spread its adoption. I know I’m striding into choppy waters here, but I can vouch for it, because I witnessed so much of the story: Winer deserves credit for a central role in getting that snowball started.

In any case, what’s more important is his argument today — that the tech industry needs to study and learn from the story of how successes like RSS unfold:

If it had been left at the “invention” stage, it would be where many other XML-related technologies are today, invented, but not much-used. Something new was done with the cloud of content, tools, aggregators, and that allowed a lot more people to use it, or hear about it, or decide it was finally time to support it.

[tags]rss, blogging, dave winer[/tags]