January 18th, 2007
I didn’t think I’d have a chance to get started reading and reviewing Dreaming in Code until next week, when I embark upon a 14-hour flight to Tokyo (click here to see an amazing HDR, or “high dynamic range,” photo of Tokyo, and be sure to click on the full-size image; thanks, BoingBoing!) But the first chapter is a short one, and I’ve got a few spare moments at the end of a long day, so let’s get started.
The first chapter is numbered zero, for reasons I’ll let you discover on your own; Rosenberg begins with two vignettes about the excitement and frustrations of writing computer programs. The first one takes place in 1975, when he was a high school student programming a game called Sumer; the second takes place in 2000, when he was a 40 year old executive at Salon magazine, in charge of a software development effort to “revolutionize” the organization’s web site with “dynamic features,” the details of which are never explained. The first effort was all-absorbing, frustrating, but ultimately successful; the second effort was equally all-absorbing, more frustrating, and apparently successful at the last moment because of several all-night work sessions.
Rosenberg uses these two vignettes as a metaphor for the industry-wide experience that while the intellectual excitement of computer programming is undiluted after 25 years, the odds of success haven’t improved much; indeed, if anything, it’s gotten much more difficult to make today’s software work. The consequences, and possible solutions, to this dilemma are presumably the subject of the remainder of the book; and it’s obviously something he feels we must discuss. As he says in the final paragraphs of the chapter,
“Software is a heap of trouble. And yet we can’t, and won’t, simply power down our computers and walk away. The software that frustrates and hogties us also captivates us with new capabilities and enthralls us with promises of faster, better ways to work and live. There’s no going back. We need the stuff more than we can hate it.
…
Some dream of ripping down the entire edifice of today’s software and replacing it with something new and entirely different. Others simply yearn for programs that will respond less rigidly to the flow of human wishes and actions, for software that does what we want and then gets out of our way, for code that we can count on.”
Well, that’s fine — and I’m looking forward to what he has to say about this great intellectual dilemma. But I must admit that I’m already a little worried, for I’ve seen no indication that he’s going to focus on what some of us see as the essence of the problem. The problem, at least to some extent, is not better programming languages, better tools, better design methodologies, or better testing techniques. The problem is people, and the communication between people.
Consider the two vignettes at the beginning of the chapter. In the first one, Scott Rosenberg labors alone, as a nerdish 15 year old student trying to make the BASIC programming language manipulate the rules of a game that simulated a city-state in the ancient Fertile Crescent. He didn’t have to communicate with anyone other than himself; he didn’t have to schedule any meetings, he didn’t have to write any memos, and he didn’t have to worry whether the “programming team” of one person was sufficiently motivated to finish the task.
In the second vignette, Rosenberg is the Managing Editor of a high-tech magazine; he’s got a Vice President of technology reporting to him, who in turn supervises a “lead programmer, [who] after working around the clock for weeks on end and finally announcing that his work was done, had taken off for Hawaii on a long-planned family vacation.” But apparently the program didn’t work after all, and apparently the VP didn’t figure that out until it was too late. There are vague references toward the end of the vignette to other “developers” (plural), and implied acknowledgments of human-inspired breakdowns in testing, documentation, supervision, change control, and goodness knows what else.
Even today, one-person programming projects have a much higher likelihood of success than the “Mongolian horde” projects involving hundreds of developers (I recall reading somewhere that the Microsoft Vista project had 4,000 developers, though I can’t seem to find any supporting documentation for that number right now; still, even if it was only 1,000 developers, it’s still a horde). And a large percentage of the truly innovative and successful software products (e.g., Visicalc, Netscape Navigator, the initial version of Google, and YouTube come to mind) were built by small teams of only a handful of people. Because our tools and technologies have improved enormously over the past 50 years, a few really gifted people can sometimes develop systems of staggering size and complexity; but since our demands and desires for technological achievements sometimes grow even faster than our technologies, we still find ourselves forming huge armies of developers to create even more massive systems … and these often fail.
Maybe all of this will be acknowledged and discussed in subsequent chapters. But I took a quick look at the index and was disappointed to find no entries for “peopleware” or Tom DeMarco’s work. On the other hand, Gerald Weinberg (author of The Psychology of Computer Programming, and many other fine books) has an entry, as does the Psychology book itself; and there are several entries under the heading of “management of software projects,” as well as entries for several other interesting people who have some very perceptive things to say about software development. So that gives me hope for the rest of the book; I’ll continue soldiering on. (Update: a couple hours after initially posting this blog entry, Scott Rosenberg graciously emailed me to confirm that (a) he is indeed aware of Tom DeMarco’s fine work, even though he didn’t have a chance to acknowledge it in his book, and (b) he does indeed emphasize the importance of people, and communication between people, in subsequent chapters of his book. Now I feel greatly encouraged, and will indeed move on to the next chapter of Dreaming in Code with great enthusiasm!)
One other brief comment at the beginning of this review process: I’ve already stumbled upon an example of the inadequacy of “dead tree” publications, the advantages and benefits of Web-based publications of the same material, and the occasional inconsistency of the two. When reading through Chapter 0, I found a reference to a Web page maintained by the ACM (”Association for Computing Machinery” for the non-geeks out there) “that lists versions of ‘Hello World’ [the first and most elementary program that anyone writes in any programming language] in nearly two hundred different languages.”
Huh! I thought. Cool! Where the heck is it? There was no footnote on the page, no URL to the aforementioned Web page; and even if there had been one, it’s pretty hard to double-click a piece of paper and expect anything useful to happen. It was only later, when I started scrounging through the index in search of my friend Tom DeMarco, that I happened to notice a section at the end of the book called “Notes,” which contained end-notes for each chapter. There were ten such notes for Chapter 0, with lots of useful information, but none of it was mentioned or identified in Chapter 0 itself. Bummer, I thought. Some editor should be hung by his thumbs until he screams for mercy.
But then I had another thought: surely, thought I, someone as clever and erudite as Scott Rosenberg can’t be oblivious of the Web! So I typed the search phrase “Scott Rosenberg Dreaming in Code” to Google, and voila! the first item at the top of the list of 244,000 items found by Google was an entire website titled DreaminginCode.com. Book reviews by other people! A blog by Scott Rosenberg! Links to Amazon and Barnes-and-Noble, where you can buy the book! Everything you would want and need!
Indeed, there’s even a link to a section called “Endnotes,” which (among other things) I hoped would provide me with a clickable version of the URL to the ACM “Hello World” page. But, sadly, here’s what I found when I clicked on the “Endnotes” link:
Many of the references in Dreaming in Code are to online resources and Web sites. When the book is published, this page will contain a version of its endnotes with all the links “live.” I’ve been writing almost exclusively for the Web since 1995, and found myself frustrated with the impossibility of doing this in the book’s print edition!
Hey Scott! The book is published; I ordered my copy from Amazon just like every other mere mortal (I wasn’t one of the lucky few who got a pre-publication review copy). So where are the contents of this page? Feh! (Update: Scott Rosenberg emailed me to say that his book had only been in the stores for two days when I posted my critical comment. And he apologized for the delay in uploading an HTML version of all the EndNotes, pointing out that he has no staff or assistants, and must do it all by himself. Okay, I’ll apologize for being so impatient … but, hey, Scott, can’t you find any interns at Stanford or Berkeley who would volunteer to do this work gratis — or have they all been hired away by Google? Just kidding; we’ll all be very grateful whenever you get a chance to get this stuff onto your website.)
For those who really want to see all of that ACM code, the “Hello World” page is here. And there are only 193 languages in the list. But why quibble over the difference between 193 and “nearly two hundred”? After all, it’s only computers we’re talking about, and computers are forgiving, right?
Well, anyway, that should be enough to keep you busy for a little while. I’ll carry on with the next chapter as soon as I get a chance…
Updated to add:
Reviews of other chapters of “Dreaming in Code”
Preface
Chapter 1: Doomed
Chapter 2: The Soul of Agenda
