“Software is a heap of trouble”. That’s the abridged version of this book.
You’ll find the full story in Scott Rosenberg‘s fantastic Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software. One part of the tale follows the progress of the Open Source Applications Foundation project called Chandler; the other wends back through the history of computer science and software development. The story takes a good chunk of paper, around 350 pages + notes. None of it is terribly technical.

Chandler started with Mitch Kapor (known for Lotus 1-2-3, among other things) and the dream of the ultimate personal information organizer. E-mail, scheduling, calendars, notes, workgroup sharing & more, all in one cohesive and flexible system. In light of Rosenberg’s Law and its corollary (“Software is easy to make, except when you want it to do something new. And the only software that’s worth making is software that does something new.”), Chandler has proven a daunting task. It’s been over 4 years since Rosenberg started observing the OSAF team. As of this writing, Chandler is currently still only in version 0.7alpha4.

That creeping glacier of code raises the question: is it the team or just the nature of the job? Probably both. Rosenberg uses the hiccups and foibles of the OSAF team to explore some of the recurring issues of software development: the inherent mental difficulty of abstraction on a mass scale, the programmer’s tendency to “glance at existing code and declare authoritatively that they could do it themselves, faster, easier, and better,” the mythical man month, attempting progress without planning, the discouraging truth of Hofstadter’s Law, and the need to reinvent the wheel (and fire and stonecutting and agriculture, etc.). Luckily, Rosenberg doesn’t pose the Chandler team so much as the butt of the joke but the foil for the argument: software is hard.

One interesting thread in this book is the idea of programming as creative writing. Quoting Richard Gabriel:

We should train developers the way we train creative people like poets and artisits… What do people do when they’re being trained, for example, to get a master of fine arts in poetry? They study great works of poetry. Do we do that in our software engineering disciplines? No. You don’t look at the source code for great pieces of software. Or look at the architecture of great pieces of software. You don’t look at their design. You don’t study the lives of great software designers. So you don’t study the literature of the thing you’re trying to build.

The software industry doesn’t have a strong sense of history. Part of that lack is cultural—many just don’t care that much—and part of that is a necessary commercial evil whereby code is protected to protect profits. But I love that idea of the literature of software, the somewhat hidden heritage. This brings to mind the idea of artist qua collector and the idea of amassing influence. But for better or worse, there’s already way too much to learn just to keep up with the present. So the programmers plug on “borne back ceaselessly into the past,” if you’ll pardon the drama.

Wikinomics: How Mass Collaboration Changes Everything was pretty much a disappointment. I wouldn’t go so far as to call it bad. I was just hoping for a less history and a more speculation. Unfortunately, if you’ve been paying a moderate amount of attention to the internet/ social software/ business world for the past few years, you won’t find much new information.
Don Tapscott and Anthony Williams have done a good job of rounding up the big trends, their so-called Principles of Wikinomics: openness, peering, sharing, and acting globally. Much of the work is a sort of biography of these paradigms and the companies & products that embody them. You probably know their names: Linux, Wikipedia, Google, Flickr, IBM, BMW, Best Buy, etc.

Each chapter reviews a new trend, fleshes out the history and summarizes by way of canned, italicized guidelines for business. I wish I hadn’t returned the book to the library already or I’d quote a few. Anyway, they also mix in a few Trendwatching-like neologisms, like “Ideagoras” and “New Alexandrians”. By far the most intriguing part of the book was Chapter 9, discussing the “wiki workplace.” Perhaps that’s because the idea is still the most nebulous and little-tested: “We are shifting from closed and hierarchical workplaces with rigid employment relationships increasingly self-organized, distributed, and collaborative human capital networks that draw knowledge and resources from inside and outside the firm” That’ll be an interesting process to see over the next few years. I think free agent/ consultant/ collaborative culture will become more and more popular.