Dreaming in Code is a one-day-at-a-time narrative of despair that Rosenberg cleverly transforms from yet another classic software team innovation story into a morality tale about the importance of humility in the creative process. For example, he does an excellent job of recapitulating the history of postwar software development as a guide to the Chandler team’s missteps. Practically every one of the most painful design issues, problems, debates, and delays confronted by Kapor’s clever developers was anticipated in, believe it or not, a NATO Software Engineering summit in 1968.
Yet Rosenberg doesn’t indulge in schadenfreude as he observes how the Chandler folks slowly but surely repeat all known pathologies of the software innovation process. Rather, he marvels at the sheer absence of historical knowledge, perspective, and discipline. “The participants recorded their frustration with the lumbering pace and uncertain results of large-scale software development and advocated many of the remedies that have flowed in and out of fashion in the years since,” Rosenberg writes. The prescriptions included calling for “feedback from users early in the design process” and “doing something small, useful, now.”
Cruelly, but not unreasonably, Rosenberg describes Linux founding father Linus Torvalds — a man who has successfully overseen the introduction and evolution of an immensely important operating system worldwide — as a Cassandra who is respected but ignored. Torvalds admonishes, “Nobody should start to undertake a large project” because “you’ll just overdesign” and be overwhelmed by your vision. “So start small and think about the details. Don’t think about some big picture and fancy design.”
Still, there’s no false dichotomy between Kapor’s grandiose aspirations and Torvalds’s studied “smaller is better” innovation heuristic. In the grander scheme of things, Torvalds is every bit as ambitious as — if not more so than — Kapor and his Chandlerians. More important, though, the Chandler team’s ambition did not make it the victim of hubris, arrogance, or egomania. These were smart, levelheaded, hardworking people. Their problem was not a surfeit of pride but a shortage of humility, at least at the outset. Over the course of the project, the team humbled itself through repeated failure: busted deadlines, broken code, and a chronic inability to manage expectations cost-effectively. If Kapor and his team had brought even 20 percent of Torvalds’s wisdom into their innovation world view, the Chandler software — and Rosenberg’s book — would have been written rather differently.
Although you won’t find it in the book’s index, humility is also the de facto theme of Scott Berkun’s The Myths of Innovation. Baked into the book’s premise is the assertion that we think we know more about the meaning, media, and mechanisms of innovation than we really do. Formerly an interface designer on Microsoft’s Internet Explorer team, Berkun now writes and lectures on creative problem solving at the University of Washington. Myths does have an occasionally annoying “everything you know about innovation is wrong” tone, but Berkun has effectively synthesized much of the traditional literature on the subject and ruthlessly debunks the rubbish.
Students and practitioners of innovation will be familiar with many of the myths Berkun pops. But his accessible writing style makes reading the myths again a pleasure. And this is one of those books where the footnotes are as important, and as enjoyable, as the text. His chapter headings neatly summarize each of the myths he eviscerates, for example: “The myth of epiphany,” “We understand the history of innovation,” “There is a method for innovation,” and “Good ideas are hard to find.” He dismisses much of what the business press (and many academics) celebrate as common sense or best practice as anecdotal foolishness. Businesses serious about value-added innovation need to disabuse themselves of the notion that they’re simply one good idea — or a good methodology — away from success.