Wordyard

Hand-forged posts since 2002

Archives

About

Greatest hits

Stealth fighter trips over dateline

February 26, 2007 by Scott Rosenberg

Back when my job as Salon managing editor involved overseeing our daily production, I noticed that, every spring and fall, almost without fail, our publishing system would experience a glitch of some kind on the weekend that the clocks got moved forward or back — nothing serious, mind you, but enough to throw a wrench in the works of our site updates. It wasn’t a single bug, but some sequence of related bugs, so we’d fix one and then six months later something else would happen. Eventually we got in the habit of just making sure that one of the developers kept a close eye on things when that weekend rolled around. It was prudent.

I thought of that as I read these accounts that are filtering out about the F-22 Raptors that, the speculation is, lost their bearings when they crossed the International Date Line. (Further speculation is that this was somehow connected to a software patch/upgrade related to the coming change in the date of Daylight Savings Time onset, but that’s harder to source.) The planes, en route to Japan, limped back to Hawaii instead

The F-22 costs $125 million or so and its operating system is written in 1.5 million lines of Ada code. It appears that, for all its “stealth” prowess and advanced weaponry, its soft underbelly may lie in the realm of the abstract.

It seems that this is one of the unexpected consequences of living in a world operated by software: new danger zones lie where human abstractions — borders, measurements, languages — change or conflict or fail to behave as expected. Clocks and calendars and maps are no longer just assists for human understanding; they are symbols at the heart of systems upon whose performance lives depend. I suppose this started with the first railway schedule, but with the dateline-addled F-22 it has entered a whole new realm of disconcert.
[tags]f-22, bugs, software[/tags]

Filed Under: Software, Technology

Teraflop software?

February 21, 2007 by Scott Rosenberg

Of the many “laws” I encountered in the course of writing Dreaming in Code, I think Wirth’s law (by the software pioneer Niklaus Wirth) is my favorite: Software gets slower faster than hardware gets faster.

Here is a contemporary instance. All right, it’s not exactly parallel; but it’s an example of the very common situation we encounter as hardware improves exponentially while software improves on only a linear basis.

This is from John Markoff’s recent piece about Intel’s demo of a prototype of a new chip-making technique that packs 80 processor cores on a single chip (the “Teraflop Chip”):

The shift toward systems with hundreds or even thousands of computing cores is both an opportunity and a potential crisis, computer scientists said, because no one has proved how to program such chips for many applications.

“If we can figure out how to program thousands of cores on a chip, the future looks rosy,” said David A. Patterson, a University of California, Berkeley computer scientist who is a co-author of one of the standard textbooks on microprocessor design. “If we can’t figure it out, then things look dark.”

Mr. Patterson is one of a group of Berkeley computer scientists who recently issued a challenge to the chip industry, demanding that companies like Intel begin designing processors with thousands of cores per chip.

In a white paper published last December, the scientists said that without a software breakthrough to take advantage of hundreds of cores, the industry, which is now pursuing a more incremental approach of increasing the number of cores on a computer chip, is likely to hit a wall of diminishing returns — where adding more cores does not offer a significant increase in performance.

I wrote about this “multicore competency” issue a couple of years ago. Looks like it’s not going away.

UPDATE: Corrected to fix a (happily) mistaken suggestion that Wirth had passed away.

Filed Under: Dreaming in Code, Software, Technology

Vista’s successor, Longhorn deja vu?

February 10, 2007 by Scott Rosenberg

Word, in the form of this Infoworld report, is beginning to trickle out from Redmond about the next Microsoft operating-system cycle. In two-and-a-half years or so, Microsoft expects to unveil Vista’s successor (code-named, apparently, “Vienna” — or maybe something else).

The report provides eerie echoes of the early days of Longhorn, as Vista was originally known. At the start of the Longhorn process in 2002 the promise was a similar 2 1/2 year delivery (see for instance this now amusing report from the WINHEC hardware conference in 2002, headlined “Longhorn slips to Late 2004”). In summer of 2003 Bill Gates and other Microsoft spokespeople began telling us about all the cool stuff Longhorn would provide. At the same time, Microsoft buckled down for what would turn out to be a year-long, all-hands-on-deck effort to tighten the security holes in Windows XP; this process resulted in XP’s “Service Pack 2” release in 2004. In 2004 Microsoft realized that the original Longhorn vision was hopelessly out of reach, and it now admits that it “rebooted” the entire development process at this point.

So that’s when Microsoft exec Ben Fathi starts the clock in looking at how long it really takes Microsoft to prepare a new edition of Windows:

Vista shipped about two-and-a-half years after XP SP 2, and Vista’s follow-up is expected to take about the same amount of time, according to Fathi. “You can think roughly two, two-and-a-half years is a reasonable time frame that our partners can depend on and can work with,” he said. “That’s a good timeframe for refresh.”

All well and good. Only when Fathi starts talking about what new stuff Vienna will have to offer users, it all sounds remarkably like what Microsoft had to say in Longhorn’s early days:

So what will be the coolest new feature in Vienna? According to Fathi, that’s still being worked out. “We’re going to look at a fundamental piece of enabling technology. Maybe its hypervisors, I don’t know what it is,” he said. “Maybe it’s a new user interface paradigm for consumers.”

Over on Engadget they’re interpreting this talk to mean stuff like “full virtualization and a radical new user interface” and “a break in compatibility with older applications.”

But to me it all sounds like: “We’re going to do big, big things, but we don’t know exactly what they are yet.” And that is precisely what Longhorn’s leaders were saying as they marched their troops down the roads that would swallow the project’s first 2-3 years.

Lesson learned?
[tags]microsoft, software, windows, vista, vienna[/tags]

Filed Under: Software, Technology

WordPress’s Pyethon trap

February 6, 2007 by Scott Rosenberg

One of the most drudge-like tasks of writing a book is assembling the endnotes, but if there is anything even more tedious, it is converting those endnotes into HTML. But I promised readers of Dreaming in Code that I would do so — so many of the references are Web-based, it makes a lot of sense to provide them with working hyperlinks.

I’d hoped to have this done before the book was published, but I’ve only just finished. Ed Yourdon wanted me to do it; how could I let him down?

But in posting this material, I discovered something very odd. Sometimes WordPress simply did not want to upload a page (I’m using WordPress’s static page feature for the whole Dreaming in Code site). At first I thought I’d hit some undocumented limit on the number of characters, or maybe number of links, on the page; or, I thought, there’s so many links on these pages, maybe it’s overloading the cool WordPress pinging/trackback stuff, so I just turned all that off.

No go. Certain pages just would not save properly, the browser would just hang. By removing chunks of text I slowly zeroed in on the problem: three notes that contained the word “Python,” as in the programming language, were causing the trouble. If I removed them, no problem!

I just tried to post one of them here as an example and this instance of WordPress won’t allow it either — it generates a “file not found” message, oddly. A quick hunt through WordPress’s documentation “codex” offered no clue. Anyone have an idea? Is WordPress’s dedication to php so intense that it will not even allow a mention of the competition?

I couldn’t even use the word “Python” in the headline of this post — it caused the same error! I had to misspell the forbidden name in order to get this post to publish properly. Very odd.

UPDATE: Thanks to the commenters who pointed me to apache’s mod_security, which is plainly to blame, and not wordpress itself. A little creative escaping of the “P” in “Python” and I now have restored the previously unpostable endnotes. Live and learn…

Filed Under: Dreaming in Code, Personal, Software

Meanwhile, back at OSAF…

January 25, 2007 by Scott Rosenberg

Anyone who reads Dreaming in Code through to the end is going to want to know what happened at the Chandler project in the time since the conclusion of the book’s narrative (it ends at the end of 2005, with Chandler at version 0.6, ready to begin some limited “dogfooding,” or use by inhouse early adopters).

Some of the early reactions to my book have presented Chandler as a total bust and proceeded on the assumption that the project is dead. That’s not at all the case. For the moment, Chandler remains a program that most people aren’t going to download and use, and it’s still not going to break any speed records. But it plainly has made steady progress over the past year. OSAF is now planning what it’s calling a “preview” release in April.

A lot more of the project’s big-picture features are now at least partially implemented — particularly the Dashboard, a sort of universal “inbox” for sorting tasks and calendar events and email according to “Getting Things Done”-style principles.

I sat down with Katie Parlante, Sheila Mooney and Mitch Kapor right before Christmas to get an update on what had happened at OSAF with Chandler during 2006.

[Read more…]

Filed Under: Dreaming in Code, Software

Lessons from MySpace: Success is a bug

January 17, 2007 by Scott Rosenberg

Apropos of my previous post on YouTube and MySpace, today I read this fascinating case-study from Baseline magazine about the saga of MySpace’s understandably overtaxed systems.

MySpace’s exploding popularity has basically forced its infrastructure through a continuous cycle of upgrades, refactorings and revampings. Its managers have never had the luxury of sitting back and calmly planning upgrades; they’ve had to perform their engine surgeries on a careening vehicle.

This is what Web 2.0 is like from the back end, and it ain’t pretty. Outside of the real masters of this stuff — the Googles and Yahoos that know how to deploy, manage and maintain vast online services — it’s a big mess. This is another little-understood dynamic of the Web 2.0 startup world: There are financial reasons a successful small service might want to be acquired, but there are even more pressing operational reasons. And the more success a service finds, the more likely it’s going to risk systems flameout.

It’s not at all clear from the Baseline piece that MySpace has yet achieved a level of stability that a more mature company might desire. MySpace, of course, was acquired not by a technology company but by a media outfit, so — unlike other popular companies that were acquired by Yahoo or Google — they’re still somewhat on their own.

The Baseline piece offers two other fascinating tidbits. In the first, a normal phenomenon for a successful site — massive surges of traffic — was interpreted as a bug by the Microsoft server platform MySpace uses:

Last summer, MySpace’s Windows 2003 servers shut down unexpectedly on multiple occasions. The culprit turned out to be a built-in feature of the operating system designed to prevent distributed denial of service attacks—a hacker tactic in which a Web site is subjected to so many connection requests from so many client computers that it crashes. MySpace is subject to those attacks just like many other top Web sites, but it defends against them at the network level rather than relying on this feature of Windows—which in this case was being triggered by hordes of legitimate connections from MySpace users.

“We were scratching our heads for about a month trying to figure out why our Windows 2003 servers kept shutting themselves off,” Benedetto says. Finally, with help from Microsoft, his team figured out how to tell the server to “ignore distributed denial of service; this is friendly fire.”

Second, it seems that MySpace didn’t actually originally intend to allow the level of customization that has made it so popular; its engineers just never got around to filtering out the user-customized formatting.

That feature was really “kind of a mistake,” says Duc Chau, one of the social networking site’s original developers. In other words, he neglected to write a routine that would strip Web coding tags from user postings– standard feature on most Web sites that allow user contributions.

The Web site’s managers belatedly debated whether to continue allowing users to post code “because it was making the page load slow, making some pages look ugly, and exposing security holes,” recalls Jason Feffer, former MySpace vice president of operations. “Ultimately we said, users come first, and this is what they want. We decided to allow the users to do what they wanted to do, and we would deal with the headaches.”

Here we have the state of Web development today: Your site’s massive success gets treated as a bug by your server; and the feature your users love best is something your programmers forgot to block.
[tags]baseline, myspace, web 2.0, software development[/tags]

Filed Under: Business, Dreaming in Code, Software

Does Web 2.0 invalidate Rosenberg’s Law?

January 15, 2007 by Scott Rosenberg

A book should stand on its own, reviews should stand on their own, and in general, it little profiteth a writer to reply directly to criticism. But at the end of his review of Dreaming in Code in the Journal (which is now available for free at this link), Paul Boutin asked me a direct question. So it doesn’t seem out of line to answer.

The author reluctantly condenses what he’s learned into Rosenberg’s Law: “Software is easy to make, except when you want it to do something new.” Cute, but MySpace and YouTube went from half-baked ideas to billion-dollar businesses while Mr. Rosenberg was writing his book. Is he saying they were hard, or that they do nothing new?

There’s no question that creating software using the Web as a platform provides multiple advantages, and has helped lots of companies, including those Boutin names, roll out products fast and improve them quickly. Web apps can be upgraded and patched without troubling the user and they come with a tight built-in user-feedback loop, so they lend themselves perfectly to an incremental improvement process, which is the smartest way to avoid the software-disaster swamp. They also solve cross-platform issues and provide sharing and collaborative features as an organic part of their environment.

This change in the software landscape is a running theme in Dreaming in Code, and one that the Chandler developers were acutely conscious of. But in today’s Cambrian explosion of Web-based applications, I can’t really think of each service as a discrete piece of software. The teeming startups of Web 2.0 are really each adding a feature or two — photo-sharing! backup! social bookmarking! word-processing! etc. — to the vast application that is the Web itself. (That’s why they make such fine acquisition-bait for the larger Web-platform companies who are competing with arsenals of such features.)

I do not intend any denigration of the huge accomplishments of the creators of both MySpace and YouTube, and I have no idea how hard or easy their development efforts were. But I think of these companies’ achievement as more in the realm of community-building than software invention. Of course they had to develop some software along the way. But their software platforms — for enabling the hang-out-together experience (at MySpace) or the sharing of short videos (on YouTube) — were not the centerpiece of their achievement. Each company refined and elaborated functions already being performed by other services. Each of them triumphed not by inventing novel extensions to the world of stuff you could do on the Web but by making things people were already doing online much easier, particularly for non-geeks.

As for their creation of “billion-dollar businesses”: remember that these are businesses that haven’t seen anything like billion-dollar revenues; they were valued by acquirers at half a billion dollars (in MySpace’s purchase by Fox) and $1.5 billion (in YouTube’s acquisition by Google)– and much of these prices was paid in stock, not cash.

Still, Boutin’s point is that both companies produced significant value quickly, and I’m not going to argue with that. But in each case what the acquisitors valued was less the code than the customers. You can be idealistic and call that “community,” or be cynical and call it “eyeballs”; either way, it’s what Google and Fox were buying.

In any case, my tongue-in-cheek Rosenberg’s Law made no claim to address the relative ease or difficulty of making money in the software business. I was trying to say something about the correlation between the ambition to innovate and the likelihood of ending up with your wheels in a ditch. MySpace wasn’t the first online hangout, and YouTube wasn’t the first video-sharing service. Instead, each of these companies went to school on their predecessors over the last decade of social media on the Web. And good for them! I imagine that what they did was “hard” in its own way — just not in the specific way that Dreaming in Code explores.

Filed Under: Dreaming in Code, Software

An interview and a profile

January 8, 2007 by Scott Rosenberg

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]

Filed Under: Dreaming in Code, Media, Personal, Software, Technology

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

January 5, 2007 by Scott Rosenberg

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…]

Filed Under: Code Reads, Dreaming in Code, Software

Office 2007: An iconoclastic view

January 4, 2007 by Scott Rosenberg

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]

Filed Under: Software, Technology

« Previous Page
Next Page »