Wordyard

Hand-forged posts since 2002

Archives

About

Greatest hits

Web 2.0’s five-year development cycle

by

As David Bowie once sang:

We’ve got five years — my brain hurts a lot
We’ve got five years — that’s all we’ve got

One of the arguments I often hear raised against Dreaming in Code’s contention that “software is hard” is what I call the “Web apps solve all our problems” stance. In this view, the Web 2.0 wave is not just about user convenience and nimble companies — it represents the final triumph over the beast of software-project delays and headaches, thanks to the ease of prototyping, the fast upgrade cycle and the tight feedback loop of user input characteristic of this approach.

No sane observer denies the importance of this trend. But I’m always a little skeptical of the pollyanna-ish view that moving our software onto the network and into the browser puts all of our old problems out to pasture.

Tonight as I caught up on my feeds I noticed two items from TechCrunch that resonated. First, Yahoo has taken its revised Web-mail interface out of beta, after years of development. (Farhad Manjoo at Salon’s Machinist has a good review.) Yahoo’s new mail system is based around that of Oddpost — a small startup that pioneered the “Ajax”-style Web interface back in 2002 before being acquired by Yahoo. I remember looking at it then and thinking, wow, this is a big deal. And it was, as the concept of updating data within a browser window without refreshing the entire page quickly spread over the next several years. But it took Oddpost from 2002 to 2007 to mature into Yahoo Mail.

Meanwhile, another key Web application that started up only a little after Oddpost, Bloglines, has introduced the first major upgrade to its interface since — well, since it began. Bloglines got acquired by Ask Jeeves years ago, and has had some problems keeping up with its masses of users and data. Even now, its new design — which looks very nice on first glance — is just entering a beta phase.

Put this together and it sounds like, after the phase of “gee whiz, we got a great idea, let’s buy a domain name and put it out there” — once reality kicks in — major Web applications have an upgrade cycle of once every five years or so. Small startups get acquired and face organizational integration challenges; small applications face the uphill struggle to scale for masses of users; and services sit through long “beta” periods to test interface choices, iron out bugs and see how they can handle running under load.

I’m not knocking Yahoo Mail or Bloglines here. But this is sobering data for those who argue that the advent of Web-based apps and services drives a silver bullet through the heart of software’s problems. Five years is no sprint. Funnily enough, it’s roughly the timespan of Windows Longhorn/Vista — or Chandler, the program I wrote about in Dreaming in Code.
[tags]software development, web 2.0, bloglines, oddpost, yahoo mail[/tags]

Bridges and code

by

Dreams of improvement in the software development field often take the form of “engineering envy,” and are frequently expressed, as I wrote in Dreaming in Code, with a fist pounded on the table and a cry of, “Why can’t we build software the way we build bridges?” In the wake of the recent bridge collapse in Minnesota we’re reminded that this comparison cuts in two directions.

Bridge-building may be a mature field, but it, too, still has its pitfalls and failures. Programmers have to worry about bit rot and security holes and edge-case bugs; civil engineers must make sure their formulas account for corrosion from bird poop.

With all this in mind, I read David Billington’s op-ed piece in last week’s New York Times, “One Bridge Doesn’t Fit All,” with great interest. One of the ways many programmers wish they could be more like bridge-builders is in the way so much of the latter’s work now consists of reusable forms and designs. Programming, by contrast, has yet to achieve the “code is Lego” dream — or rather, though developers have greatly benefited from what Robert Glass calls “reuse in the small” (pulling small bits of code, libraries of routines or objects, off the shelf), “reuse in the large” remains mostly out of reach.

Billington’s argument is that design-by-committee procedures and reuse of one-size-fits-all plans have impoverished bridge-building in America. He wants to see bridge projects led by “one engineer who makes the conceptual design, understands construction and has a strong aesthetic motivation and personal attachment to the work.” While many programmers yearn to increase the ratio of science to art in their field, Billington is urging the bridge-builders in the opposite direction.

It’s not easy to balance demands for safety and beauty and thrift. “American bridge engineering largely overlooks that efficiency, economy and elegance can be mutually reinforcing ideals,” Billington writes. “This is largely because engineers are not taught outstanding examples that express these ideals.” He wants engineers to study great examples of bridge design just as Richard Gabriel wants programmers to study great classics of code. (The new book Beautiful Code opens some doors in that direction.)

While the civil engineers seek to learn from the Minnesota collapse, software developers can, for a moment at least, set aside their “bridge envy,” and think about some of the ways the two fields resemble each other. For instance: Disasters can never be eliminated. But at least we can keep improving our ability to postpone them.
[tags]bridges, software development, programming, dreaming in code, david billington[/tags]

Berkeley talk, Chandler, Barcamp, Citizen Josh

by

I have been hunkered down getting my life (and a mountain of notes and research) in order. Here’s a grab-bag of items:

  • On Wednesday I spent the afternoon at UC/Berkeley at the kind invitation of Bill Allison, and talked with a thoughtful, interested group of faculty, administrators and IT people about Dreaming in Code and the wider topic of software’s innate difficulties. Berkeley, along with a number of other institutions, is about to kick off an ambitious project to build a new platform for much of its underlying digital infrastructure. Chandler, whose slow progress Dreaming in Code chronicled, has a university tie-in as well, and these folks are smart and foresightful enough to want to try to understand what pitfalls they might be facing.

    Too often, groups embark on big new software ventures as if they are the first pioneers ever to walk down their particular path, when in fact most of the field is full of well-worn roads (and the roads usually lead into one or another ditch). So hats off to my Berkeley neighbors for wanting to study an at least partial map of the terrain.

  • Speaking of Chandler, the folks at OSAF are closing in on a major release, called Preview, later this month. I’ll be writing more about it here as it unfolds.
  • Barcamp Block: This marks the second anniversary of Barcamp, a self-organizing conference for geeks, startup companies and related phenomena. It’s down in Palo Alto this coming weekend, it looks like great fun and interesting people, and I’m planning to be there, at least for the first day.

[tags]uc berkeley, chandler, barcamp, josh kornbluth[/tags]

Falling bridges and failing programs

by

Last week I was reviewing my Dreaming in Code slides and talk, which include a brief discussion of the old question, “Why can’t making software be more like building bridges?” when the news hit of the Minneapolis bridge collapse. In the book I used the long and painful stop-start process of the Bay Bridge replacement (a bridge that stopped for a redesign in mid-construction!) as one example of how bridge building may not be as reliable and predictable an undertaking as we think; the Minneapolis tragedy is another example.

At least it’s getting people thinking. For those interested in further reading, there’s Stephen Wolfram’s fascinating post suggesting that future bridge designs may emerge from the sort of mathematical explorations his software has enabled:

what should the bridges of the future look like? Probably a lot less regular than today. Because I suspect the most robust structures will end up being ones with quite a lot of apparent randomness….we’re going to end up being exposed to something really quite new. Something that exists in the abstract computational universe, but that we’re “mining” for the very first time to create structures we want.

Computerworld reports on new systems that allow the placement of acoustic sensors on bridges to provide better feedback mechanisms than today’s routines of visual inspection.

I was also reminded of a thorough and informative paper from 1986 that I came across in my Dreaming in Code research: “Case Study: A Computer Science Perspective on Bridge Design,” by Alfred Spector and David Gifford. (There’s a PDF available here.) This paper outlines the more mature and rigorous process of designing and specifying a new bridge and systematically compares it to the looser and less clearly defined processes we use in so much software engineering.
[tags]bridges, software engineering, stephen wolfram[/tags]

The way the Gates mind works

by

Bill Gates took a kind of victory lap in the press on Monday, with dueling big pieces in the Times and the Journal marking his steadily advancing separation from the company he started three decades ago. While the Journal concentrated on the role that Craig Mundie will take over from Gates — as Microsoft’s long-term software thinker — John Markoff’s Times piece featured some choice quotes from the soon-to-retire founder himself.

First, there was Gates the Google-baiter, adopting a role he has played a lot in recent years:

“How many products, of all the Google products that have been introduced, how many of them are profit-making products?” he asked. “They’ve introduced about 30 different products; they have one profit-making product. So, you’re now making a prediction without ever seeing the software that they’re going to have the world’s best phone and it’s going to be free?”

Then there was Gates the true believer in software:

The center of gravity in the computer industry has dramatically shifted toward software, he said. “Why do you like your iPod, your iPhone, your Xbox 360, your Google Search?” he said. “The real magic sauce is not the parts that we buy for the Xbox, or the parts that Apple buys for iPhones, it’s the software that goes into it.”

Finally, there was Gates the slightly tongue-tied global debugger:

Mr. Gates insists that his new world of philanthropy will be just as compelling as software has been. “I’ll have also malaria vaccine or tuberculosis vaccine or curriculum in American high schools, which are also things that, at least the way my mind works, I sit there and say, ‘Oh, God! This is so important; this is so solvable,’ ” he said, “You’ve just got to get the guy who understands this, and this new technology will bring these things together.”

If that’s the spirit that has inspired Gates to use his fortune for good causes, then one should probably not complain. But there is something so very naive about this richest-man-in-the-world’s can-do engineering spirit.

Problems? You’ve just got to get the “guy who understands”! Give him the right technology! And all will be well.
[tags]microsoft, google, bill gates, philanthropy, new york times, john markoff[/tags]

Notes from Mashup Camp

by

I spent a few hours on Wednesday at Mashup Camp — I think this was the 4th event, the second I’ve attended. As previously I found most value in the “speed geeking” portion: an hour or two spent moving from table to table in a big room hearing a succession of five-minute demos by developers showing off some cool trick or application mashup. Last year I wrote about what it all means:

…you got a window onto a simpler, faster, and perhaps smarter approach to software product development — one that trades in the virtue of from-the-ground-up consistency and thoroughness for the even more compelling virtue of “getting something working fast.” It’s software development as a Darwinian ocean in which large numbers of small projects are launched into the water. Only a handful will make it to land. But most of them required so little investment that the casualty rate is nothing to lose sleep over.

This time I’ll just mention a few demos that I thought stood out:

  • Chime.tv: This is essentially a kind of Del.icio.us for videos, with a smart built-in video player and some basic tools for building and sharing channels. Nothing revolutionary here, except that (a) it lets you aggregate videos you find all over the Web (not just one provider like YouTube) into your own playlist/channel; and (b) it happens to be remarkably well-designed. I expect to be using it for a while as a video-viewing manager. We’ll see how it holds up.
  • Myk O’Leary’s twitterlicious serves as a simple hookup between Twitter and Del.icio.us (or Ma.gnolia.com). In other words: If you’re reading Twitter messages (“Tweets”) on a mobile device and they contain URLs that are inconvenient to save and that you can’t properly visit at the moment, Twitterlicious sends the “tweet” to your Del.icio.us account as a private bookmark with a special tag. You can review these at your desktop leisure.
  • Lignup showed a cool little application that lets you use your cellphone as a mobile input device to add voice annotation to a Web page or object (like, for instance, a Flickr photo). (This press release tells a little more.)

This Mashup Camp was a little less mobbed than the last one I went to, but there still seemed to be plenty of good ideas. And I even bumped into a few people who’d read Dreaming in Code, which always puts me in a good mood.

This weekend I’m going to try to go to at least some of WordPress Camp. Then next week my family will be doing some actual camping — like, in a tent. I think we’ll call it Camp Camp.
[tags]mashup camp, mashup camp 4, mashups[/tags]

Slaves to the inbox

by

My latest Salon article is “Empty thine inbox” — a piece about e-mail overload hitched to reviews of three current books: “Send,” an e-mail etiquette guide by David Shipley and Will Schwalbe; Mark Hurst’s “Bit Literacy,” which outlines a methodology for personal-information management; and Mark Frauenfelder’s “Rule the Web,” a treasury of tips and tricks for taking control of, and enjoying, one’s online life.

The piece takes a brave stand against the injunction to maintain strict inbox hygiene:

My inbox is not a desk that must be cleared. It is a river from which I can always easily fish whatever needs my attention. Why try to push the river? Computer storage is cheaper than my time; archiving is easier than deleting… Do we really want the job of in-box attendant and e-mail folder file clerk? The mess is Augean scale, the job Sisyphean futile.

One other angle on this subject that I did not work into the article comes from Ducky Sherwood, who wrote books on how to handle e-mail burdens some years ago (and who also has a great resource page on all things email):

I’m a bit bothered by an implicit characterization that “email is the problem.” This isn’t fair to the medium. Your problem is that lots of people give you stuff to do. (“Read my message” falls into the category of “stuff to do”.) People have been overwhelmed by the amount of stuff that other people give them to do since long before email.

[tags]productivity, email, gtd, pims, personal information management[/tags]

Code Reads #11: “Notes on Postmodern Programming”

by

Code ReadsThis is the eleventh 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.

Playfulness in writing about programming isn’t always so easy to find. But here it is again. In our last Code Reads we got to enjoy Guy Steele’s words-of-one-syllable language game; this time around, we’re in the hands of two writers who are playing games with the entire corpus of software history.

James Noble and Robert Biddle are colleagues at Victoria University in Wellington, New Zealand (Biddle is now at Carleton University in Ottawa). In Dreaming in Code I summarized a bit of their work (along with a group of colleagues) on “Scale-free geometry in OO programs” — a study which found that software objects are “scale-free, like fractals, and unlike Lego bricks.”

Earlier this decade Noble and Biddle presented a series of papers at the OOPSLA conference on the theme of “Postmodern Programming.” The first, “Notes on Postmodern Programming” (2002), opens with a tongue-in-cheek transposition of the Bauhaus manifesto into the computing realm. From there, it jumps into a sometimes line-by-line rewrite of Edsger Dijkstra’s “Notes on Structured Programming” (which we looked at back in Code Reads #4). So we’re on notice that this paper will draw heavily on the postmodern aesthetic of cobbling together scraps, references, tributes and parodies.

But those bits and pieces form a serious argument, too.
[Read more…]

Jaron Lanier’s surface-embracing vision

by

Near the end of Dreaming in Code I took a chapter to look at some of the more visionary efforts today to reform the troubled world of software development. One key portrait was of Jaron Lanier. (It was a delightful coincidence that, well after I’d settled on my book title, I discovered that Lanier had once told an interviewer, “I used to dream in code at night when I was in the middle of some big project.”)

This month in his column in Discover, Lanier uses my book as a jumping off point to discuss some of the same questions I set out with:

Why do some software projects sail to completion while so many others seem cursed? Why must software development be so difficult to plan?

These questions should concern everyone interested in science, not just programmers, because computer code is increasingly the language we use to describe and explore the dynamic aspects of reality that are too complicated to solve with equations. A comprehensive model of a biological cell, for instance, could lead to major new insights in biology and drug design. But how will we ever make such a model if the engineering of a straightforward thing like a personal productivity package confounds us?

In the heart of the piece, Lanier explains, more fully, his big idea — “phenotropics”: a software system, inspired by biology and robotics, in which surfaces “read” each other using fuzzy pattern recognition, allowing for systems that are better able to handle small variations from the norm without crashing.

Suppose software could be made of modules that were responsible for identifying each other with pattern recognition. Then, perhaps, you could build a large software system that wouldn’t be vulnerable to endless unpredictable logic errors.

He mentions Web 2.0-style mashups as one fledgling step in this direction, and also provides an anecdotal account of a project from the 1980s that he collaborated on with Andy Hertzfeld (another central figure in Dreaming in Code) called Embrace.

It’s a mind-expanding read, like so much of Jaron’s stuff. Embrace surfaces! Find patterns!
[tags]jaron lanier, phenotropics, software crisis[/tags]

Code Reads #10: Guy Steele, “Growing a Language”

by

Code ReadsThis is the tenth 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.

You don’t have to read too far into Guy Steele’s “Growing a Language” to figure out what he’s up to. In this 1998 talk on the nature of programming-language design, Steele writes under a set of constraints: he may use any word of one syllable, but if he wishes to use longer words, he must define them first — using only words of one syllable.

Steele aimed to illustrate how awkward and confining it can be to try to express yourself when you don’t have access to an extensive vocabulary: “I wanted to show you want it is like to use a language that is much too small.” (By this point in the talk, he has already defined “language.”) His larger purpose is to advocate a philosophy of programming-language development that aims for neither a small nor a large language, but rather for one that is “designed to grow.”

Such growth is to be propelled not by a closed cadre of gurus but by the language’s users, who have been given an appropriate set of tools to extend the language. The shape of the language is such that these user-generated additions do not look or behave any differently from the “original” elements of the language provided by its initial creators. Nearly a decade later, this argument — which parallels similar ideas that have become popular in the open-source software community as well as in the “user-generated” enthusiasms of Web 2.0 — sounds neither arcane nor controversial.
[Read more…]