This one I picked up because I read an excerpt on Salon.com, which made it sound enticing. And the first half was. It's about a group led by the guy who invented Lotus 1-2-3 (the early dominant spreadsheet program). They are trying to create something that they never called an Outlook killer though it seemed like one to me, and they're having a rough time. The book is non-fiction, something I had to keep explaining to the people I was telling about. I write computer manuals and dabble in project management in my day-job, and a lot of the anecdotes told in this book made me chuckle and shake my head. They had problems with the word "item", which meant different things depending on the person using the word; we have problems with the word Devices, and the word Preset (we have a Preset folder on the interface, and then subfolders that are also called Preset folders, but those preset subfolders hold presets, and are also called presets. I rewrote the documentation using a hierarchy of Preset folder, preset subfolders, and presets which can be activated individually or in a subfolder group.) Anyway, this was a book that I kept referring to at work while I was reading it; a lot of it related.
And then, halfway through the book, the story disappeared. I don't expect a plot per se for non-fiction, but there were two chapters of summations from different experts about why software sucks, and how it should suck less, and the history of sucking software. These anecdotes were interesting, but they went on too long. I mean, Chandler, the outlook killer, was barely mentioned for about 65 pages. And then there were the last two chapters, which seemed like an afterword, really. I felt like the author had abandoned the team. And in a sense he had. They had been working for years, and they were supposed to have shipped product by now, but I guess the book had to go to print. The ending was totally unsatisfying. I'll ruin it for you: Chandler didn't ship as of the publication date. I just checked the project's website (yay, google!) and they released version 0.7 on November 30, 2006. I guess they missed their 1.0 release date of spring '07, because, well, Spring ended last week. Maybe I found the ending unsatisfying because the book was due and I had to finish it because the library wouldn't let me renew (someone else had a hold on it) so I had to finish it in a two-day 150-page binge.
I will still quote this book to other people -- I learned a lot. "Your project will take longer than you think, even if you take into account that it will take longer than you think." "Software is hard." But the first half is way better than the second.
And then, halfway through the book, the story disappeared. I don't expect a plot per se for non-fiction, but there were two chapters of summations from different experts about why software sucks, and how it should suck less, and the history of sucking software. These anecdotes were interesting, but they went on too long. I mean, Chandler, the outlook killer, was barely mentioned for about 65 pages. And then there were the last two chapters, which seemed like an afterword, really. I felt like the author had abandoned the team. And in a sense he had. They had been working for years, and they were supposed to have shipped product by now, but I guess the book had to go to print. The ending was totally unsatisfying. I'll ruin it for you: Chandler didn't ship as of the publication date. I just checked the project's website (yay, google!) and they released version 0.7 on November 30, 2006. I guess they missed their 1.0 release date of spring '07, because, well, Spring ended last week. Maybe I found the ending unsatisfying because the book was due and I had to finish it because the library wouldn't let me renew (someone else had a hold on it) so I had to finish it in a two-day 150-page binge.
I will still quote this book to other people -- I learned a lot. "Your project will take longer than you think, even if you take into account that it will take longer than you think." "Software is hard." But the first half is way better than the second.