Special

Introducing the “Welcome to Xojo” Bundle!

New to Xojo and looking for guidance? We've put together a terrific bundle to welcome you! Xojo Bundle

This bundle includes six back issues of the magazine -- all of year 16 in printed book and digital formats -- plus a one-year subscription (beginning with 17.1) so you'll be learning all about Xojo for the next year. It's the perfect way to get started programming with Xojo. And you save as much as $35 over the non-bundle price!

This offer is only available for a limited time as supplies are limited, so hurry today and order this special bundle before the offer goes away!

Article Preview


Buy Now

Issue 5.4

REVIEW

Book: Dreaming in Code

Issue: 5.4 (May/June 2007)
Author: Marc Zeedar
Article Description: No description available.
Article Length (in bytes): 7,240
Starting Page Number: 9
Article Number: 5404
Related Web Link(s):

http://www.crownpublishing.com/

Full text of article...

I've never worked on a large multi-person software project so I can't claim to understand the complexities of collaborative development. But the subject of Salon co-founder Scott Rosenberg's new book still intrigued me. The subtitle of the book is "Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software," and it's the story of a failed software venture.

At least that's what I thought it was. It turns out the software project's not exactly a failure -- it's just not finished yet -- and the book merely uses that story as a way to cover the broad topic of software development.

Considering how much of modern society depends on software -- it's everywhere, from cell phones to cars -- software is amazingly difficult to create. What I found most revealing about Rosenberg's book is that this is not a new phenomena. Even as computers have gotten faster and programming languages more sophisticated, the problems software attempts to tackle have gotten exponentially larger, and more and more large projects are years behind schedule, full of bugs, and inherently flawed (witness Microsoft's Vista). Our ambitions still exceed our abilities.

In chapter 10 Rosenberg brilliantly demonstrates how this is nothing new by giving us a series of quotes from a software engineering conference where experts said stuff like, "We build systems like the Wright brothers built airplanes -- build the whole thing, push it off a cliff, let it crash, and start over again." Sounds familiar, right? But then Rosenberg reveals that this conference happened in 1968!

"Why can't we build software the way we build bridges?" It's a question asked by many and this book explores the problem. Are we using the best tools? Do methodologies to track software development work or just slow down programmers? Is software engineering a science or an art?

In discussing these questions, Rosenberg covers vast amount of ground, going from Frederick P. Brooks' classic works and legends like Alan Kay and Knuth to interviewing modern visionaries like Linus Torvalds, Eric Raymond, Charles Simonyi, and many others, and the variety of perspectives is fascinating.

For instance, Kay -- the inventor of object-oriented programming -- feels that today's versions of OOP have bastardized his ideas and only use a fraction of the capabilities he envisioned. Another man, Jaron Lanier, proposes an interesting pattern-based approach to programming ("phenotropic software"), inspired by biology.

Then there's the view of Sun engineer Richard Gabriel who's convinced that the problem with software development lies in the training: "We should train developers the way we train creative people like poets and artists." After all, he argues, if software's an art form, it should be taught like one. How does one teach artists? You have them study the works of masters. But that's not done in software engineering -- the source code's locked up and so developers keep making the same mistakes made fifty years ago!

All this thought-provoking theory might be dreary except that Rosenberg mixes it in with the dramatic story of a software venture. The project seemed to have everything going for it. It was organized and funded by Lotus 1-2-3 creator Mitch Kapor, a Silicon Valley legend, who had decided to invest some of his millions into creating an open source company that would invent a revolutionary kind of information management technology. Kapor's "change the world" vision was broad and inspiring: he quickly attracted talent like Andy Hertzfeld (one of the original Macintosh developers) and Lou Montulli (Netscape cofounder). It seemed like an ideal way to start a company. What could go wrong?

The answer, of course, is everything. We watch as the company struggles to tame its grand vision into something realistic. We see personality conflicts, differences in philosophy, arguments over coding environments, and painful compromises. Rosenberg peppers all these stories with vivid anecdotes, famous quotations, and historical events that add insight into the current crisis, showing us that though Kapor's company seems to be making unprecedented mistakes, the experience is nothing new, and in fact, not even unusual. Unusual would be the software project that finishes on time and under budget!

What I found most surprising is how much I understood and related to the problems Kapor's company was experiencing. Even asa sole developer I've struggled with various aspects of software development: overly ambitious goals, lack of time, slipped ship dates, bugs that seem impossible to find, design flaws that aren't seen until late in development, code walls, "yak shaving" (building the tool you need so you can build the real tool you have to have to finish the project), and those frustrating days when it seems you work and work and work but nothing gets accomplished.

Not being trained as a programmer, I figured these problems were unique to me; I'm relieved to discover I'm normal!

Unfortunately, while this is a fascinating and important book, it asks more questions than it answers, and the story of Kapor's company is frustratingly incomplete. It doesn't have an ending since the software isn't finished yet. Rosenberg had a publishing deadline and didn't want to wait to see what would happen to the software, so the big question -- is Kapor's venture a success or a failure -- is left unanswered. That leaves the book's conclusion vague and undetermined.

But if you're curious about software development and how projects can go wrong, this is a book worth reading. It's written like a novel interspersed with commentary. And you get to learn about and from all sorts of famous computer people. What could be better than that?

End of article.