Search Site
This site uses cookies to deliver our services, improve performance, for analytics, and (if not signed in) for advertising. By using LibraryThing you acknowledge that you have read and understand our Terms of Service and Privacy Policy. Your use of the site and services is subject to these policies and terms.
Hide this

Results from Google Books

Click on a thumbnail to go to Google Books.


Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One… (2007)

by Scott Rosenberg

MembersReviewsPopularityAverage ratingMentions
8612420,752 (3.6)10
Why is software so hard? Hard to make well. Hard to deliver on time. Hard to use. Our civilization runs on software, yet the art of creating it continues to be a dark mystery, even to the experts, and the greater our ambitions, the more spectacularly we seem to fail. This book sets out to understand why, through the story of one software project--Mitch Kapor's Chandler, an ambitious, open-source effort to rethink the world of email and scheduling. Journalist Rosenberg spent three years following the work of the Chandler developers as they scaled programming peaks and slogged through software swamps. Here he tells their stories.--Adapted from www.dreamingincode.com.… (more)

Sign up for LibraryThing to find out whether you'll like this book.

No current Talk conversations about this book.

» See also 10 mentions

Showing 1-5 of 24 (next | show all)
Jaron Lanier mentioned this book in his Dawn of the New Everything (and Rosenberg mentions Lanier in here a couple of times...crossover: "Computer scientist Jaron Lanier tells a story about an encounter between the young Engelbart and MIT’s Marvin Minsky, a founding father of the field of artificial intelligence. After Minsky waxed prophetic about the prodigious powers of reason that his research project would endow computers with, Engelbart responded, 'You’re gonna do all that for the computers. What are you going to do for the people?' "). Being an old programmer from the mainframe/teletype/punch card days, I was intrigued, so I read it in parallel while on vacation last week. I knew little of this effort to create Chandler; I was in Korea as it grew, and still there when it died. A mix of the history of the application, the people involved, and of the technology, this is a story of the modern application: lots of promise, and lots of problems. From the description of the vision(s), Chandler would have been great. But...it never came to be. Other apps establish dominance regardless of inferiority (MS Word still can't do the inline formatting that Word Perfect did.) Yes, I use Outlook, and the rest of the M$ Office Suite. I don't use their browser, but it's an inconvenience to buck the trend to interact with the world. Perhaps somebody will come along with an PIM as versatile as the Chandler dream. (No, web based stuff from Google, etc. are clumsy and well, inconvenient.)

One really good insight (of many) found near the end: My view is that we should train developers the way we train creative people like poets and artists. People may say, ‘Well, that sounds really nuts.’ But 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.” Brilliant, right? So why do they study great code? (A snarky answer might be "because there isn't any?") Algorithms, yes, but so many languages and systems have those algorithms already embedded. On the insistence of my advisor, I took a grad school class on finite element analysis that turned out to be building the code ourselves, not using it for analysis. And no, all we had was the textbook and a professor who cut the semester short to go on a speaking tour in India. Anyway, this is an idea with merit.

Selected highlights and notes:

[on Frederick Brooks, who wrote the 1975 book The Mythical Man-Month, a jumping off point] Brooks was a veteran IBM programming manager who had seen firsthand the follies of the largest software project of its day, the creation of the operating system for the IBM System/360 [...] And so he formulated Brooks’s Law, which is both a principle and a paradox: “Adding manpower to a late software project makes it later.”
Find (Lanier also referenced it) And Brooks's Law also applies to construction. Too many painters in a room don’t make it finish sooner.

[Jumping off point] The work ["Framework for the Augmentation of Human Intellect"] culminated in a legendary public demonstration in 1968 at the San Francisco Convention Center. A video of that event is still available online, which means that today anyone can, by following some Web links and clicking a mouse, watch Engelbart introduce the world to the very idea of a link, and the mouse, and many other elements of personal computing we now take for granted.

[on "brain muscle memory"] That’s a limitation of the world of physical objects. But there are advantages, too. Once you’ve lived with your arrangement a while, you discover you can locate things based on sense memory: Your fingers simply recall that the Elvis Costello section is over at the right of the top shelf because they’ve reached there so many times before.
I so know this. After we restored our house from a fire, in which we lost 5,800 books (along with almost everything else), I would walk into what was the library but never again, and instantly know Tolkien was there, Chalker there, my religion books over there… I still had the memories 8 years after the library was destroyed and none of those books existed,

[on software development] Because it so often takes ages before a new piece of software is ready for anyone to use, programmers often test their assumptions against “use cases”—hypothetical scenarios about how imaginary people might need or want to use a program
Modern application implementation teams do this as well to customize an existing app to a new user group

[jumping off point] Eric Raymond had written in The Cathedral and the Bazaar
In case I didn’t flag this already, find

[on] Object-oriented programming: More than any other of the arcane terms that have migrated beyond the closed world of the programmer, this one has resisted clarity and invited misunderstanding. Even after reading hundreds of pages on the subject, discussing it with experts, and attending a number of lengthy lectures on the topic, I cannot say with 100 percent confidence that my own explanation of the phrase will satisfy every reader.
I’m so old school, having cut my teeth on Fortran and Basic before assemblers, that I still have the “new” versions of “structured programming” to overcome.

[on existing code] The world is full of code that someone else has written. Shouldn’t it be easy to grab it and use it for your new project? Why then do so many programmers glance at existing code and declare authoritatively that they could do it themselves, faster, easier, and better?
Hubris. There can be some fun in deciphering, then recasting and then rewriting, only to determine that misunderstanding the initial coding led to cascading errors… or the rare, I actually did fix it.

[on Apple's silly metric of "lines of code written"] If counting lines of code is treacherous, other common metrics of software productivity are similarly unreliable.
I had to deal with meaningless measures in my last job... number of work orders, dollars spent… non normalized, non contextualized useless data

[on MBWA] The informal approach to managing technical projects achieved its most famous incarnation at Hewlett-Packard with the concept of “management by wandering around,” which was later popularized by Tom Peters’s In Search of Excellence. This rigorous methodology requires managers to leave their offices, visit workers in their dens, and chat them up. “How’s it going?” may not sound like the most incisive or analytical line of inquiry, but management by wandering (or walking) around was revolutionary in its way: It suggested that it was less important for managers to pore over ledgers than for them to get out and observe what their employees were actually doing. It placed a premium on human observation and contact. It is an excellent management method.

[jumping off point] Christopher Alexander’s book A Pattern Language
Find (found...it's a tome)

[on Mitch Kapor's Software Design Manifesto] A lot of Kapor’s manifesto may sound self-evident today, but his assertion that designers should take the lead in creating software remains controversial. Some programmers look down on the very idea of design and designers, and are quite certain they are the best arbiters of how their programs should look and behave
Tom Peters and others advocate incorporating designers in everything. I agree. And... I know that designers must be managed!

[on a Big Mistake (my opinion, not theirs)] Getting Things Done suggests that modern life and work leave us mentally beset by a host of incomplete tasks: physical objects lying around us waiting to be dealt with, incoming emails that need to be answered or filed, documents and publications that we’re supposed to read, things we’ve promised other people we will do. This heap of “open loops” collectively constitutes what Allen calls our “stuff.” GTD proposes that we can stop feeling overwhelmed by our stuff and take charge of it by creating a “trusted system”—on paper or digitally, it doesn’t matter. Oh, dear. Awful awful book and methodology. My review is here, but the short of it was “You have a choice: you can Get Things Done, or you can actually get things done.” Seems that Chandler opted for the former… and died.

[Michael Toy, speaking to the author after he left the Chandler team] Mitch Kapor is spending millions of dollars a year and does not want to have responsibility for little details. He wants to find someone to make sure his money is being well spent. And that’s a level of detail that I could not provide. And a level of assurance that I could not provide. Mitch was really patient in just saying, ‘I will help you get better at these things.’ So I have no complaints about the position I was in. But in the end, I was just being asked to provide a service that I wasn’t very good at. Get someone NOT in the business. This is the trap almost every organization falls into - they think you have to know everything about the business to succeed in managing it. My wife edited English versions of Samsung phone and copier/printer user manuals and made them better because she wasn’t an engineer … she asked why do you have this button? Or how it that a new feature? (True life example. The engineers’ answer? We moved that button to the right side from the left.) The key in that was that she was an end user and thought like one, not like the engineers.

[on the author's misunderstanding of Fortran and Basic] Like a film editor making a jump cut, GOTO simply dropped one story line that a program was developing and picked up another. It handed off control from one point in a program to another unconditionally, taking nothing else into account—neither the values of different variables nor the state of the program and its data.
Not really…GOTO was used inside the program and the values remained until control left the program. Now, function calls and subroutines were different.

[Watts Humphrey's summary of the Capability Maturity Model] An organization at Level 1 is basically not doing much of anything. At Level 2, they’re doing some planning, tracking, configuration management, they make some noises about quality assurance, that kind of stuff. A Level 3 organization begins to define processes—how they work, how they get things done, trainable things. At Level 4 they’re using measurements. They have a framework for actually tracking and managing what they do, something statistically trackable. Level 5 organizations have a continuously improving process.

[the author] Once, while interviewing a job candidate at Salon, I apologetically described the state of disarray of our technical operation at the time. “Ahhh,” said the interviewee with a diplomatic smile. “Then you’re using agile methodology!”
Yeah… yet another buzzword for less than useful methodology. I dealt with salespeople of the words; and I worked with a handful who actually made it work.

[on Joel Spolsky, former project manager for Microsoft]In another essay he writes: “Beware of Methodologies. They are a great way to bring everyone up to a dismal but passable level of performance, but at the same time, they are aggravating to more talented people who chafe at the restrictions that are placed on them. It’s pretty obvious to me that a talented chef is not going to be happy making burgers at McDonald’s, precisely because of McDonald’s rules.”

[on object oriented programming] To Kay’s dismay, Smalltalk’s most radical innovations never made great headway in the software marketplace, and the kind of object-oriented programming that took over the computing mainstream in the nineties is, in his view, a bastardization. (“I made up the term object-oriented,” he says, “and I can tell you, I did not have C++ in mind.”

[on true open source software] Lanier’s “Gordian Software” article provoked a firestorm of criticism on the Edge.org Web site, John Brockman’s salon for future-minded scientists. Daniel Dennett accused Lanier of “getting starry-eyed about a toy model that might—might—scale up and might not.” But Lanier is unfazed. He says his critique of software is part of a lifelong research project aimed at harnessing computers to enable people to shape visions for one another, a kind of exchange he calls “post-symbolic communication” and likens to dreaming—a “conscious, waking-state, intentional, shared dream.”

[jumping off point] The Art of Computer Programming shows programmers how to design and test algorithms for efficiency.
Found. And it is huge! multiple volumes and subvolumes. It may not be something I'll ever have time to tackle. ( )
  Razinha | Apr 9, 2022 |
Mitch Kapor (of Lotus 1-2-3 fame) has the misfortune of funding an ambitious software project just as the World Wide Web was going through its Web 2.0 phase. It's a complicated story, related in a lot of detail, but without any heroes and without a happy ending. ( )
  superpatron | Feb 25, 2019 |
Rosenberg attempts to do for software what Tracy Kidder did for hardware in 'The Soul of a New Machine' back in the early 1980s. Rosenberg follows a team of software developers as they attempt to build an alternative personal information manager called Chandler to compete with Microsoft's Outlook and match/extend the capabilities of the Lotus Agenda product (Chandler was originated and initially funded by Mitch Kapor, the developer of Lotus 1-2-3). Well, we all know where that story ended - Chandler was eventually released in 2008 and after a few minor updates a final release was made available in 2009, since when the product has signally failed to fire much enthusiasm.

Rosenberg provides an interesting narrative of how the Chandler product development proceeded, but fails to put any real life into the story, leaving us unsatisfied and generally uninterested in what is going on and what the ultimate fate of the story is (the book was published before the final product was released and its subsequent fade-to-black). The problem here is that Rosenberg cannot decide if this is a book about software development or about project management. Software development is a devilish tricky thing to write about - how do you make the story of a guy (usually, a guy) staring into space for a while and then typing esoteric technical stuff into a computer something that people want to read about? At least project management involves human interaction and has some historical backstory (Rosenberg leverages Fred Brooks' 'The Mythical Man-Month' throughout).

As an insider (I have worked in the computer industry for 40+ years) I found this an interesting and relevant book. For non-geeks who want peek inside the kimono I don't think this gives them any more insight and understanding of what software development is than they had before. ( )
  pierthinker | Dec 7, 2015 |
A decent look at software development for those unfamiliar with the field. Not all software development is as hard as Chandler -- this was a good effort, but there's more to be said about what KINDS of things in software development are hard, and why. Chandler struggled with having too few constraints. No fixed budget or deadline allows for a lot of wheel-spinning. Also struggled with trying to build a platform as opposed to just a program, which is a common desire to be sure. Spoiled by a bad case of the Architecture Astronaut. ( )
  steve.lane | Nov 28, 2015 |
As CIO at a small college, I had the distinct unpleasure of signing purchase orders for software license renewals and maintenance contracts. In what other business would you buy a product that costs enormous sums of money, is guaranteed to be flawed, will require frequent and costly upgrades, never lives up to its promises, and requires a team of lawyers to interpret the contract, not to mention days of very expensive training for your staff. Welcome to the world of software.

Rosenberg follows the progress of the development of a software package from idea through development and debugging to end (actually, there is no end and to my knowledge they are still trying to come up with a workable product that may have already been superseded by others.). A major difficulty of development is getting many hundreds of programmers to work together and integrate their work into a cohesive product. Not to mention major resdeisgns in the middle of the project - try that with a bridge. The section on learning how to manage the project is worth the cost of the book. Programmers are well known for spending as much time designing the tools to help them use the tools and to save them time using the tools to work on the project than on the code itself.

"But in much of the business world today there lies, beneath the wide dissatisfaction with how software projects perform, a deeper anxiety—a fear that the root of the problem may lie not in failures of management technique but in the very nature of the people doing the work. To many executives, and even to their coworkers in sales or other parts of a company, programmers often seem to belong to an entirely different species. Communicating with them is frustratingly hard. They fail to respond to applications of the usual reward/punishment stimuli. They are geeks, and they are a problem."

I'm not a programmer, yet I found this book fascinating reading and learning about the dynamics of creating some of these monstrous programs. Vista, anyone?

Similar recommended titles: [b:The Soul of a New Machine|7090|The Soul of a New Machine|Tracy Kidder|http://photo.goodreads.com/books/1165606419s/7090.jpg|882196] by Tracy Kidder.

OK, I admit it. I'm adding a quote that is very interesting but it also represents my playing around with my clippings file on the Kindle to see how easy it is to save and export quotes, etc. Really easy, as it turns out. This one relates to the difficulty of managing programmers (kind of like herding cats) and much of the reason stems from the attributes (almost an autistic or Asperger's personality -- in fact, there has been an explosion of diagnosed autism in Silicon Valley) of programmers.

"Forty-one percent of the IT professionals surveyed reported being introverted thinkers (combination of introversion and thinking preferences), nearly twice the percentage in the general population. Introverted thinkers often prefer a lone-gun approach to work, often avoiding teams, collaborative efforts, and the training that support such structures. This group is least likely to engage and connect interpersonally with others, and may avoid creating personal bridges of trust and openness with colleagues. . . A lot of people feel that communicating with the information technology professional is just slightly harder than communicating with the dead,” Abby Mackness, an analyst with Booz Allen Hamilton who conducted the Human Dynamics study, joked as she presented its results to a crowd of defense contractor employees and consultants."

( )
  ecw0647 | Sep 30, 2013 |
Showing 1-5 of 24 (next | show all)
no reviews | add a review
You must log in to edit Common Knowledge data.
For more help see the Common Knowledge help page.
Canonical title
Original title
Alternative titles
Original publication date
Important places
Important events
Related movies
Awards and honors
Software is hard

— Donald Knuth, author of The Art of Computer Programming
For my parents.
First words
The shelves of the world are full of how-to books for software developers.
Last words
(Click to show. Warning: May contain spoilers.)
Disambiguation notice
Publisher's editors
Original language
Canonical DDC/MDS
Canonical LCC

References to this work on external resources.

Wikipedia in English (3)

Why is software so hard? Hard to make well. Hard to deliver on time. Hard to use. Our civilization runs on software, yet the art of creating it continues to be a dark mystery, even to the experts, and the greater our ambitions, the more spectacularly we seem to fail. This book sets out to understand why, through the story of one software project--Mitch Kapor's Chandler, an ambitious, open-source effort to rethink the world of email and scheduling. Journalist Rosenberg spent three years following the work of the Chandler developers as they scaled programming peaks and slogged through software swamps. Here he tells their stories.--Adapted from www.dreamingincode.com.

No library descriptions found.

Book description
Haiku summary

Popular covers

Quick Links


Average: (3.6)
1 2
1.5 2
2 8
2.5 4
3 59
3.5 7
4 70
4.5 5
5 22

Is this you?

Become a LibraryThing Author.


About | Contact | Privacy/Terms | Help/FAQs | Blog | Store | APIs | TinyCat | Legacy Libraries | Early Reviewers | Common Knowledge | 173,624,634 books! | Top bar: Always visible