What do you think?
Rate this book
Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software
Their story takes us through a maze of dead ends and exhilarating breakthroughs as they and their colleagues wrestle not only with the abstraction of code but with the unpredictability of human behavior, especially their own. Along the way, we encounter black holes, turtles, snakes, dragons, axe-sharpening, and yak-shaving—and take a guided tour through the theories and methods, both brilliant and misguided, that litter the history of software development, from the famous ‘mythical man-month’ to Extreme Programming. Not just for technophiles but for anyone captivated by the drama of invention, Dreaming in Code offers a window into both the information age and the workings of the human mind.
416 pages, Hardcover
First published January 16, 2007
162 people are currently reading
3,354 people want to read
About the author
Scott Rosenberg
18 books13 followersWriter, editor and website builder SCOTT ROSENBERG is a cofounder of Salon.com and author of Say Everything: How Blogging Began, What It's Becoming and Why It Matters and Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest For Transcendent Software.
Librarian Note: There is more than one author in the GoodReads database with this name. See this thread for more information.
At Salon, Scott served as technology editor and, from 1999 to 2004, as managing editor and vice president for editorial operations. He also started the Salon Blogs program in 2002 and began his own blog as part of it. Before leaving Salon in 2007 to write SAY EVERYTHING he conceived and prototyped the Open Salon blogging community.
Before Salon he wrote on theater, movies, and technology for the San Francisco Examiner for a decade and was honored with the George Jean Nathan Award for his reviews. His writing has appeared in the New York Times, Wired, and many other publications. He lives in Berkeley, California, with his wife and two sons.
Librarian Note: There is more than one author in the GoodReads database with this name. See this thread for more information.
At Salon, Scott served as technology editor and, from 1999 to 2004, as managing editor and vice president for editorial operations. He also started the Salon Blogs program in 2002 and began his own blog as part of it. Before leaving Salon in 2007 to write SAY EVERYTHING he conceived and prototyped the Open Salon blogging community.
Before Salon he wrote on theater, movies, and technology for the San Francisco Examiner for a decade and was honored with the George Jean Nathan Award for his reviews. His writing has appeared in the New York Times, Wired, and many other publications. He lives in Berkeley, California, with his wife and two sons.
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 243 reviews
May 3, 2009
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: The Soul of a New Machine 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."
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: The Soul of a New Machine 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."
October 25, 2009
I dithered a long time on whether or not to read this book; probably mostly because it's hard to believe that it's actually not about coding.
It's not about coding.
Certainly there's a lot about coding in it, but it's about working with people, attempting to solve unsolvable problems, history of programmatic problem-solving... I know, it sounds like it's about coding. And, I have to say, it's a must-read for anyone who even remotely works with software -- be it creating or using. It's a story about business, about creativity, about writing, about man coming face-to-face with his/her own intellectual and philosophical limitations.
It's definitely a gem if you work in software development. But it's probably more fascinating if you don't; it has some of the best explanations of not only the field, but its history, its complications, its characters and its motivations.
And before I stop gushing about the book qua substance, let me say that it wouldn't come close to succeeding if it weren't so well-written.
It's not about coding.
Certainly there's a lot about coding in it, but it's about working with people, attempting to solve unsolvable problems, history of programmatic problem-solving... I know, it sounds like it's about coding. And, I have to say, it's a must-read for anyone who even remotely works with software -- be it creating or using. It's a story about business, about creativity, about writing, about man coming face-to-face with his/her own intellectual and philosophical limitations.
It's definitely a gem if you work in software development. But it's probably more fascinating if you don't; it has some of the best explanations of not only the field, but its history, its complications, its characters and its motivations.
And before I stop gushing about the book qua substance, let me say that it wouldn't come close to succeeding if it weren't so well-written.
June 20, 2008
This book had some interesting anecodetes, but overall, it sounded like a software engineering after-school special. Rosenberg made the software development lifecycle sound like it's as mystical experience, akin to studying the Kabballah (it's not), and he missed the mark on defining certain programming concepts (eg "late-binding") in a way that made me suspect he was trying to overdress his comprehension of the subject.
The truth is, this book does not describe a typical software project. Chandler's biggest problem, was that the programmers had too much time and money. I know, that sounds ridiculous, but the reality is, 3 years to punch out a distributed calendar application that never made it to a production release is sort of depressing. I downloaded the current version of Chandler, and while it has some interesting features, they missed the mark by making it a desktop application instead of a web-enabled one, a fact that was quietly mentioned in the last 50 pages of the book.
I will say that there's a lot of really interesting anecdotes, and I appreciate Rosenberg's ambition in trying to create a narrative about programming that would be appealing to both techies and non-techies. However, I subtract points because he used the word "dynamic" too much...which I hate.
The truth is, this book does not describe a typical software project. Chandler's biggest problem, was that the programmers had too much time and money. I know, that sounds ridiculous, but the reality is, 3 years to punch out a distributed calendar application that never made it to a production release is sort of depressing. I downloaded the current version of Chandler, and while it has some interesting features, they missed the mark by making it a desktop application instead of a web-enabled one, a fact that was quietly mentioned in the last 50 pages of the book.
I will say that there's a lot of really interesting anecdotes, and I appreciate Rosenberg's ambition in trying to create a narrative about programming that would be appealing to both techies and non-techies. However, I subtract points because he used the word "dynamic" too much...which I hate.
December 5, 2007
Dreaming in Code was an awful lot of fun, a good uplifting "Chicken Soup for the 3l33t Soul" kinda thing. I bought copies for everyone in my office. On the other hand, the first two chapters (after a strong, catchy Introduction, sigh) are downright painful, any code company that allows loud, messy dogs into the bowels of their austere Rigorium is obviously destined to fail, and what's up with all these girls writing code? I don't know how they do it on the West Coast, but I quote Ed Post's modern classic, "Real Programmers Don't Use Pascal":
"In general:
* No Real Programmer works 9 to 5. (Unless it's the ones at night.)
* Real Programmers don't wear neckties.
* Real Programmers don't wear high heeled shoes.
* Real Programmers arrive at work in time for lunch.
* A Real Programmer might or might not know his wife's name. He does, however, know the entire ASCII (or EBCDIC) code table.
* Real Programmers don't know how to cook. Grocery stores aren't open at three in the morning."
All predjudices aside, no matter how savory, I've got to say any team that couldn't kick out a glorified calender after three years ought give up code authoring and become, say, mercenaries for hire in those delightful colonial shakeouts, or do a 'quarter' in the Sevvostlag acquiring expertise in Siberian tree harvesting, or teach "Coaching Principles and Strategies of Basketball" at the University of Georgia (http://www.thesmokinggun.com/archive/...).
Contains a nice collection of programming quotes from some of the Old Grandmasters, which most CS folk will/should know but might be new to you.
"In general:
* No Real Programmer works 9 to 5. (Unless it's the ones at night.)
* Real Programmers don't wear neckties.
* Real Programmers don't wear high heeled shoes.
* Real Programmers arrive at work in time for lunch.
* A Real Programmer might or might not know his wife's name. He does, however, know the entire ASCII (or EBCDIC) code table.
* Real Programmers don't know how to cook. Grocery stores aren't open at three in the morning."
All predjudices aside, no matter how savory, I've got to say any team that couldn't kick out a glorified calender after three years ought give up code authoring and become, say, mercenaries for hire in those delightful colonial shakeouts, or do a 'quarter' in the Sevvostlag acquiring expertise in Siberian tree harvesting, or teach "Coaching Principles and Strategies of Basketball" at the University of Georgia (http://www.thesmokinggun.com/archive/...).
Contains a nice collection of programming quotes from some of the Old Grandmasters, which most CS folk will/should know but might be new to you.
August 31, 2016
This book is paradoxically similar to the content it covers—and therein lies the problem. Dreaming in Code follows (for a three year period) the genesis and subsequent never-ending development of the open-source Chandler personal information manager (PIM) project. As the book relates the meandering development process, much like Lawrence trekking through Arabia, so too does the actual chapter by chapter account. Just as you are settling in as an invisible listener at design meetings, suddenly you are thrust into a chapter-long recantation of some particular aspect of historical software engineering design. I'm sure this was done in order to appeal to the luddite-fringe in the book crowd, but to seasoned veterans this is just plain frustrating. Sort of like sitting in your college calculus class and then suddenly having the teacher talk about the basics of addition. Which ties me to the problem with the book. If you are going to tout the book as the next generation successor to Soul of a New Machine, at least follow the phenomenal lead set by Mr. Kidder and tell the story about the people behind the machine—that's what sells and lasts the test of time. Technology comes and goes but it's the story of people which remain etched in time. To paraphrase, sorry but Dreaming in Code, you are no Soul of a New Machine. BTW, the end story told on the last two pages is priceless.
February 6, 2010
I found this book to be fascinating. I learned quite a bit, too, about all the factors that programmers consider when they start a new project. Lots of interesting anecdotes. Also, I found that you can actually download the software that the team developed (and is still developing!) and try it out.
January 7, 2025
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:
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.
Find
[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]
[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)]
[Michael Toy, speaking to the author after he left the Chandler team]
[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]
[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.
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.
Find
[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.
September 10, 2015
Subtitle: Two Dozen Programmers, Three Years, 4.732 Bugs, and One Quest for Transcendent Software.
In 1981, Tracy Kidder's book “Soul of a New Machine” was published. It chronicled the triumphant effort at Data General to design and build a new computer. It was an improbable hit, winning a Pulitzer Prize, and exposing the bizarre culture inside the then still new(ish) world of computer design. Rosenberg here is attempting to do the same for software, chronicling the development of an open source project called Chandler (envisioned as a sort of replacement for Outlook). But, what do you do if the project you're chronicling never gets released?
Actually it did, eventually, but years later than scheduled, and Rosenberg had to give up waiting and publish his book early. In some ways, “Dreaming in Code” is a perfect story about software, showing how a bunch of very smart and dedicated people, working together, can make every project management mistake in the book.
They choose the wrong strategy at a very early stage (application rather than web service), and as the passage of time reveals this, they are too invested in their early decisions to pull up stakes and change plans. They take too long to make decisions, trying to avoid strategic errors, and as a result spend long periods of time not accomplishing much. When they finally decide, they make errors anyway, because really the only way to know which choice is the right one is to not choose it, then go back and choose again. They overpromise early, then fail to deliver a working minimal product for years, leading to disenchantment among the would-be customer community.
How did a bunch of smart, motivated, skilled people working together fail to produce a usable product for years? This is the question that Rosenberg realizes his book is meant to address, albeit not the theme he imagined when he began. I resist here the urge to summarize his points, or my own view (not entirely overlapping with his), but one could summarize it by saying that Software Is Hard, and Software Development Is Poorly Understood.
Rosenberg's effort at building a coherent narrative around this is not an unalloyed success, but I think he captures all the important points, and in some ways the unsatisfying nature of the story is part of the its value. Software development is fundamentally different than, say, digging a ditch, and no amount of planning or process or methodology can change that. You don't know you've dug the ditch until it's fully dug. You don't know how far you've gotten until you've finished, and at any point short of that there is the very real possibility that you've gotten nowhere, because you've gone in the wrong direction. Software development is more like inventing than it is like building, and its progress is inherently unpredictable. No matter how much money, smarts, or good intention you have, you won't know if you've headed down the right path until you either hit paydirt, or fail to.
Yes, even you.
In 1981, Tracy Kidder's book “Soul of a New Machine” was published. It chronicled the triumphant effort at Data General to design and build a new computer. It was an improbable hit, winning a Pulitzer Prize, and exposing the bizarre culture inside the then still new(ish) world of computer design. Rosenberg here is attempting to do the same for software, chronicling the development of an open source project called Chandler (envisioned as a sort of replacement for Outlook). But, what do you do if the project you're chronicling never gets released?
Actually it did, eventually, but years later than scheduled, and Rosenberg had to give up waiting and publish his book early. In some ways, “Dreaming in Code” is a perfect story about software, showing how a bunch of very smart and dedicated people, working together, can make every project management mistake in the book.
They choose the wrong strategy at a very early stage (application rather than web service), and as the passage of time reveals this, they are too invested in their early decisions to pull up stakes and change plans. They take too long to make decisions, trying to avoid strategic errors, and as a result spend long periods of time not accomplishing much. When they finally decide, they make errors anyway, because really the only way to know which choice is the right one is to not choose it, then go back and choose again. They overpromise early, then fail to deliver a working minimal product for years, leading to disenchantment among the would-be customer community.
How did a bunch of smart, motivated, skilled people working together fail to produce a usable product for years? This is the question that Rosenberg realizes his book is meant to address, albeit not the theme he imagined when he began. I resist here the urge to summarize his points, or my own view (not entirely overlapping with his), but one could summarize it by saying that Software Is Hard, and Software Development Is Poorly Understood.
Rosenberg's effort at building a coherent narrative around this is not an unalloyed success, but I think he captures all the important points, and in some ways the unsatisfying nature of the story is part of the its value. Software development is fundamentally different than, say, digging a ditch, and no amount of planning or process or methodology can change that. You don't know you've dug the ditch until it's fully dug. You don't know how far you've gotten until you've finished, and at any point short of that there is the very real possibility that you've gotten nowhere, because you've gone in the wrong direction. Software development is more like inventing than it is like building, and its progress is inherently unpredictable. No matter how much money, smarts, or good intention you have, you won't know if you've headed down the right path until you either hit paydirt, or fail to.
Yes, even you.
October 31, 2009
Y'know, there were things about this book that were really, really great. Mostly, it was that this is a fantastic overview of computers, software, and the culture of those who make them. Want to know why code should be free ("free like speech, not like beer")? Ever heard of a "wiki" and wondered what it was? Did you know that "nerd" is uncool but "geek" is hot? This book, using fantastically accessible metaphors and descriptions, will tell you.
What's not so hot, though? Two things. The first is that the rest of the book (about a third of it, I'd guess) is about the journey a particular company took to try to create a new software product. And while the journey is interesting, it's told waaaaay too slowly. Of course, part of the point of its story is that it took waaaaay too long to develop the product, so the storytelling matches the real life progression. But still. If you want me to read, you need to tell me about the train wreck in something faster than slow motion.
My second, and much more minor complaint, is that the author seems to think that the world of computers is the be-all and end-all and pinnacle of everything. As a single example, Rosenberg talks about the "quality triangle": how you can have any two of the three qualitities of fast, cheap, and good in production. Then he says (p. 119), "You can't labor long in any engineering realm without encountering this painful formula, but it is in the world of software... that the quality triangle has fully come into its own." Really? Besides your own biased viewpoint, why should we think that the computing world is *more* true for this than any other field? I found this bias a number of times, though it was so subtle that Scott never noticed. Not a deal-breaker, for sure, if the rest of the topic interests you.
What's not so hot, though? Two things. The first is that the rest of the book (about a third of it, I'd guess) is about the journey a particular company took to try to create a new software product. And while the journey is interesting, it's told waaaaay too slowly. Of course, part of the point of its story is that it took waaaaay too long to develop the product, so the storytelling matches the real life progression. But still. If you want me to read, you need to tell me about the train wreck in something faster than slow motion.
My second, and much more minor complaint, is that the author seems to think that the world of computers is the be-all and end-all and pinnacle of everything. As a single example, Rosenberg talks about the "quality triangle": how you can have any two of the three qualitities of fast, cheap, and good in production. Then he says (p. 119), "You can't labor long in any engineering realm without encountering this painful formula, but it is in the world of software... that the quality triangle has fully come into its own." Really? Besides your own biased viewpoint, why should we think that the computing world is *more* true for this than any other field? I found this bias a number of times, though it was so subtle that Scott never noticed. Not a deal-breaker, for sure, if the rest of the topic interests you.
January 21, 2019
I kept seeing this book getting recommended on Hacker News and I finally decided to give it a go. And it did not disappoint. The book offers a good overall summary of the state of the Software industry - and it’s both a good intro for “laymen” and an interesting book for people who work in the industry. I never heard of Chandler before reading the book, but the startup project quickly grew on me because of the subject-matter (a PIM app - Personal Information Manager), the project being open-source and because of the founder: Mitch Kapor.
Kapor had a great idea - which unfortunately has YET to be realized: an app to manage all personal information in a single place (be it email, calendar, task management, notes, wiki etc) by transforming/converting the data as needed & by having great sharing & collaboration features.
The sharing & collab aspect has improved a lot since those days - as both web & mobile apps have started to become increasingly popular in the last decade. However information is still separated in different ‘silos’ - which means duplicated info & effort to sync everything together. If you are a GTD nerd you know what I’m talking about - and you should definitely read this book.
They had a great idea, they had the right approach, the money to keep going without any revenue & enough smart and dedicated people. But software is Hard - and the project’s cause of failure is difficult to isolate. This is my main takeaway from the book. It happens to the best programmers & projects, so we shouldn’t be surprised if we see it in the companies we work for or in our own personal projects.
Kapor had a great idea - which unfortunately has YET to be realized: an app to manage all personal information in a single place (be it email, calendar, task management, notes, wiki etc) by transforming/converting the data as needed & by having great sharing & collaboration features.
The sharing & collab aspect has improved a lot since those days - as both web & mobile apps have started to become increasingly popular in the last decade. However information is still separated in different ‘silos’ - which means duplicated info & effort to sync everything together. If you are a GTD nerd you know what I’m talking about - and you should definitely read this book.
They had a great idea, they had the right approach, the money to keep going without any revenue & enough smart and dedicated people. But software is Hard - and the project’s cause of failure is difficult to isolate. This is my main takeaway from the book. It happens to the best programmers & projects, so we shouldn’t be surprised if we see it in the companies we work for or in our own personal projects.
October 19, 2013
I'm a developer and this book was a little painful for me to read. Dreaming in Code covers the development of Chandler, an ambitious project that fell very short of its goals.
There were lots of points in the book where I wanted to yell "What the heck are you doing!?" It seemed like a textbook trainwreck of what not to do in a software project.
What I found valuable is that the author is a journalist and not a programmer so he was able to provide a different lens for viewing the successes and failures of the Chandler project. This was an interesting perspective for me because I now look at the world from a pretty technical perspective. Aside from that perspective, there wasn't much in the book that I really found valuable.
Read this book if you want to learn how not to develop software.
There were lots of points in the book where I wanted to yell "What the heck are you doing!?" It seemed like a textbook trainwreck of what not to do in a software project.
What I found valuable is that the author is a journalist and not a programmer so he was able to provide a different lens for viewing the successes and failures of the Chandler project. This was an interesting perspective for me because I now look at the world from a pretty technical perspective. Aside from that perspective, there wasn't much in the book that I really found valuable.
Read this book if you want to learn how not to develop software.
August 2, 2017
Enjoyed listening to this book.
It touches on a lot of issues in a software developer/managers life.
The problem that I had, was this book mostly state all the problems, without giving any helpful solutions to try out.
That and the fact that the main case-study was still in early stages of development by the time the book was completed.
Besides mostly not getting anything valuable out of the book, it is a breath of fresh air that you are not alone in having certain problems.
And basically that there is no single recipe / guideline on how to do things right.
Something that hit the nail on the head, was the fact that you cannot write code without creating bugs. And small bugs could take indeterminable time to fix.
I did have quite a chuckle when it came to estimation being referred to as a SWAG (Sophisticated Wild-Ass Guess)
Would recommend to anyone dealing with problems in the development life-cycle, purely for having a chuckle at the issues we deal with and how it gets perceived by various people.
It touches on a lot of issues in a software developer/managers life.
The problem that I had, was this book mostly state all the problems, without giving any helpful solutions to try out.
That and the fact that the main case-study was still in early stages of development by the time the book was completed.
Besides mostly not getting anything valuable out of the book, it is a breath of fresh air that you are not alone in having certain problems.
And basically that there is no single recipe / guideline on how to do things right.
Something that hit the nail on the head, was the fact that you cannot write code without creating bugs. And small bugs could take indeterminable time to fix.
I did have quite a chuckle when it came to estimation being referred to as a SWAG (Sophisticated Wild-Ass Guess)
Would recommend to anyone dealing with problems in the development life-cycle, purely for having a chuckle at the issues we deal with and how it gets perceived by various people.
April 15, 2013
Dreaming in Code is a book about software development. As a software developer, I cannot tell you how many times I completely related to the proceedings. All of the mistakes, all of the problems, all of the concerns, all of the date slipping, everything. It all felt so familiar, so "been there, man". To some extent, that's the problem with the book.
I've tried to read Dreaming in Code on 3 separate occasions. The idea sounded interesting, and the title alone piqued my interest, so I purchased the hardcover book when it came out. I tried reading it, but simply was unable to get into it. A few years later, I acquired the ebook, so I could read it any time like on the bus or on my phone. I got a bit further, but still lost interest. Finally, I made it through the book by buying the audiobook version of it and listening while driving or working out. It somewhat perplexed me that I had such a hard time getting into the book, considering that I found "Masters of Doom", a very similar book about the struggles of a series of software projects (Wolfenstein, Doom, Quake, etc) to be one of the best books I read in the last year.
The difference between these two books lies in how they were written. Masters of Doom was written after the fact, by interviewing people associated with the projects and assembling an historical narrative from these accounts. Dreaming in Code was written by an embedded journalist, who was actually IN the offices where the software was being written, writing about it as it was being developed and eventually picking an arbitrary point in time to cut the book and release it. The difference is important, for one simple reason. Masters of Doom was allowed to be about some of the most groundbreaking games ever created, with the full knowledge of history at the disposal of the author. Dreaming in Code is about the development of a personal information manager called Chandler, which I never heard of before reading the book.
Masters of Doom was fun not only because I could relate to so many of the trials and tribulations of software development that it discussed, but also because I was familiar with the software itself and interested in its history. Chandler is just some Outlook-esque type program, some boring office software meant to emulate Lotus Agenda (which I had also never used). As such, there is nothing interesting about the software itself or its history, so all that's left in Dreaming in Code is the process of development software, and the issues that arise.
As a longtime software developer, these issues were so familiar to me that I found it almost boring. I was so familiar with these woes that it didn't feel like I was really learning anything or gaining new insight. There were occasional passages that I found enlightening, and I wound up definitely taking a handful of "look this up later" type notes, but they were few and far between in light of the book's considerable length. The book almost would be better suited for someone who was NOT familiar with the process of software development, but as countless conversations about my workday with my wife have indicated, nonprogrammers tend not to give a flying rat's fuck about the process of software development.
I would recommend this book, but not to developers, nor to people with no connection to development. I'd recommend it to anyone who works at a company that develops software, but who is not actually on the development team. Salespeople, customer support, maybe even high-level managers, those sorts of folks. I think the book sheds a lot of light on what goes wrong with development projects, and people whose lives are affected by development projects may well find it very interesting and clarifying. It might also be good for those who are interested in becoming software developers, or college students majoring in Software Engineering or Computer Science (but be warned, the Chandler project is particularly dysfunctional, and I recognized its problems mostly from the worst jobs I've ever had, not the best). Those who live this life will find it boring, as will anyone whose interactions with software are limited to its usage.
I've tried to read Dreaming in Code on 3 separate occasions. The idea sounded interesting, and the title alone piqued my interest, so I purchased the hardcover book when it came out. I tried reading it, but simply was unable to get into it. A few years later, I acquired the ebook, so I could read it any time like on the bus or on my phone. I got a bit further, but still lost interest. Finally, I made it through the book by buying the audiobook version of it and listening while driving or working out. It somewhat perplexed me that I had such a hard time getting into the book, considering that I found "Masters of Doom", a very similar book about the struggles of a series of software projects (Wolfenstein, Doom, Quake, etc) to be one of the best books I read in the last year.
The difference between these two books lies in how they were written. Masters of Doom was written after the fact, by interviewing people associated with the projects and assembling an historical narrative from these accounts. Dreaming in Code was written by an embedded journalist, who was actually IN the offices where the software was being written, writing about it as it was being developed and eventually picking an arbitrary point in time to cut the book and release it. The difference is important, for one simple reason. Masters of Doom was allowed to be about some of the most groundbreaking games ever created, with the full knowledge of history at the disposal of the author. Dreaming in Code is about the development of a personal information manager called Chandler, which I never heard of before reading the book.
Masters of Doom was fun not only because I could relate to so many of the trials and tribulations of software development that it discussed, but also because I was familiar with the software itself and interested in its history. Chandler is just some Outlook-esque type program, some boring office software meant to emulate Lotus Agenda (which I had also never used). As such, there is nothing interesting about the software itself or its history, so all that's left in Dreaming in Code is the process of development software, and the issues that arise.
As a longtime software developer, these issues were so familiar to me that I found it almost boring. I was so familiar with these woes that it didn't feel like I was really learning anything or gaining new insight. There were occasional passages that I found enlightening, and I wound up definitely taking a handful of "look this up later" type notes, but they were few and far between in light of the book's considerable length. The book almost would be better suited for someone who was NOT familiar with the process of software development, but as countless conversations about my workday with my wife have indicated, nonprogrammers tend not to give a flying rat's fuck about the process of software development.
I would recommend this book, but not to developers, nor to people with no connection to development. I'd recommend it to anyone who works at a company that develops software, but who is not actually on the development team. Salespeople, customer support, maybe even high-level managers, those sorts of folks. I think the book sheds a lot of light on what goes wrong with development projects, and people whose lives are affected by development projects may well find it very interesting and clarifying. It might also be good for those who are interested in becoming software developers, or college students majoring in Software Engineering or Computer Science (but be warned, the Chandler project is particularly dysfunctional, and I recognized its problems mostly from the worst jobs I've ever had, not the best). Those who live this life will find it boring, as will anyone whose interactions with software are limited to its usage.
August 15, 2009
I was given this book as a gift from the Computing Sciences Dept. at Villanova for the Best Independent Study 2006 award. It looks like a great book and I am looking forward to reading it.
Update after reading it
Great book! If you want to understand what us software engineers do all day, or how the software you use everyday gets built, this is the book. No technical expertise or programming experience is required to enjoy this book -- there's only one tiny little example of code in the whole book. Rosenberg completely nails the field and the mindset of its denizens. He gets it! Everything he says and explains is correct and accurate and relevant -- I say this with authority because he is writing about my profession. He doesn't miss a single one of the big ideas in software engineering, and explains them in a way that both technical and non-tech reader will appreciate. If you are technical, you'll read with a knowing smile and will find yourself nodding in savvy agreement, and you'll enjoy the case study about the Chandler project.
I am seriously considering making this book required reading for a graduate course I'm teaching on software engineering. I would love it if my friends and family read this book, because I think the software industry in which my husband and I have worked for ~13 years is not well-understood outside its close-knit ranks. I think it would help them to understand how our minds work and what our work life is like. What an amazing feat of journalism!
Update after reading it
Great book! If you want to understand what us software engineers do all day, or how the software you use everyday gets built, this is the book. No technical expertise or programming experience is required to enjoy this book -- there's only one tiny little example of code in the whole book. Rosenberg completely nails the field and the mindset of its denizens. He gets it! Everything he says and explains is correct and accurate and relevant -- I say this with authority because he is writing about my profession. He doesn't miss a single one of the big ideas in software engineering, and explains them in a way that both technical and non-tech reader will appreciate. If you are technical, you'll read with a knowing smile and will find yourself nodding in savvy agreement, and you'll enjoy the case study about the Chandler project.
I am seriously considering making this book required reading for a graduate course I'm teaching on software engineering. I would love it if my friends and family read this book, because I think the software industry in which my husband and I have worked for ~13 years is not well-understood outside its close-knit ranks. I think it would help them to understand how our minds work and what our work life is like. What an amazing feat of journalism!
May 5, 2009
This book was interesting because the author switched back and forth between the history/current state of software and an open source development project. The insider view into the project and the background development made for an interesting read.
I most enjoyed the chapter "Engineers and Artists" where the development of software is compared with the art of writing. A good writer (and software developer) will revise and have his or her work reviewed many times before considering it finished. While timelines do not always allow software to be "perfect" as a classic novel, refactoring is important. Rosenberg brings up the additional point that artists (painters, musicians, writers, etc) study the work of other good art, to learn from it as part of their training. Doing more of this in software makes a lot of sense. We don't really study good programs, or have access to a lot of source code most of the time. Every developer and software manager seems to have to reinvent the wheel every time they write code or start a new project, which is why utilizing open source communities and technical blogs can be so important to becoming a better developer.
I most enjoyed the chapter "Engineers and Artists" where the development of software is compared with the art of writing. A good writer (and software developer) will revise and have his or her work reviewed many times before considering it finished. While timelines do not always allow software to be "perfect" as a classic novel, refactoring is important. Rosenberg brings up the additional point that artists (painters, musicians, writers, etc) study the work of other good art, to learn from it as part of their training. Doing more of this in software makes a lot of sense. We don't really study good programs, or have access to a lot of source code most of the time. Every developer and software manager seems to have to reinvent the wheel every time they write code or start a new project, which is why utilizing open source communities and technical blogs can be so important to becoming a better developer.
February 24, 2013
I don't recommend this book if you are a software engineer or manager, or any other kind of insider in the software development. You'll find little useful or interesting information here and lots of annoying demagogy. The only informative places were those that quoted books and articles on the matter written by professionals. However, the author did have one true epiphany: at the middle of the book he wrote that if the reader were a software engineer, he probably had thrown his book at the other corner of the room by then. I would have done the same if it wasn't an audio book. By the way, the reader of an audio book suited the overall annoying and dilettante tone very well by over-dramatizing every single sentence.
I can't see how outsiders can be interested in this book either: the detailed agony over databases, widgets' libraries and GUI design that is so familiar to software developers must be pretty boring to anybody else.
The only audience I can recommend this book to are journalists that don't know much about the matter but nevertheless want to come up with an "insightful" book about software development.
I can't see how outsiders can be interested in this book either: the detailed agony over databases, widgets' libraries and GUI design that is so familiar to software developers must be pretty boring to anybody else.
The only audience I can recommend this book to are journalists that don't know much about the matter but nevertheless want to come up with an "insightful" book about software development.
March 30, 2009
For any programmer, especially any programmer who has worked in a large team, this will ring true. For managers of programmers, even more so!
The story, still ongoing, of a programming team attempting to write an 'ultimate' piece of software. Not like some sci-fi book, tho. Not some software to control the world or be the next killer app - just scheduling, notes, tasks... something 'simple'.
As the book points out, even with no constraints from others, building software from scratch is a daunting task - and I know. With my team, I created a whole new class of software for my company. No one oversaw or dictated the need for us. We saw the need, we designed the solution and we delivered the software. It soon became absolutely essential to the running of the business.
For me, there were many parallels to my experiences in this story. The writing is true, crisp, funny and delves deeply into things outside the story itself.
Another book well worth the time spent reading it.
The story, still ongoing, of a programming team attempting to write an 'ultimate' piece of software. Not like some sci-fi book, tho. Not some software to control the world or be the next killer app - just scheduling, notes, tasks... something 'simple'.
As the book points out, even with no constraints from others, building software from scratch is a daunting task - and I know. With my team, I created a whole new class of software for my company. No one oversaw or dictated the need for us. We saw the need, we designed the solution and we delivered the software. It soon became absolutely essential to the running of the business.
For me, there were many parallels to my experiences in this story. The writing is true, crisp, funny and delves deeply into things outside the story itself.
Another book well worth the time spent reading it.
October 4, 2007
I have a degree in computer science, and my thesis in remote sensing involves a lot of programming. Despite that, I wouldn't ever describe myself as a programmer. I can do a little programming, I can do a little admin work, but I am not a normal computer professional.
It was refreshing to see other people having the same issues I do. I have an idea...I spec out how long it ought to take......and it is consistently only 1/2 (at best!) the time I need.
Computers are either insanely complex or insanely simple, maybe both at the same time. It seems like there is still much more of an art to programming though, rather than a science.
It was refreshing to see other people having the same issues I do. I have an idea...I spec out how long it ought to take......and it is consistently only 1/2 (at best!) the time I need.
Computers are either insanely complex or insanely simple, maybe both at the same time. It seems like there is still much more of an art to programming though, rather than a science.
June 30, 2017
Great book, very interesting. The main topics are many of the technical and not-so technical aspects of software development, explained clearly and in an understandable way, even for non-programmers.
Sometimes reading about the development cycles of "Chandler" is quite exasperating, as the people commit all sorts of errors (as programmers or as humans) while you scream "don't do that" in your head. But while one of the programmers decides for the n-th time to change the "object storage system", you simply know you'd probably make the same assumptions and the same errors...
A realistic insight in software development. As Donald Knuth puts it: "Software is hard."
Sometimes reading about the development cycles of "Chandler" is quite exasperating, as the people commit all sorts of errors (as programmers or as humans) while you scream "don't do that" in your head. But while one of the programmers decides for the n-th time to change the "object storage system", you simply know you'd probably make the same assumptions and the same errors...
A realistic insight in software development. As Donald Knuth puts it: "Software is hard."
August 5, 2015
This was an ok examination of the difficulties of actually developing software. My biggest complaint is that
February 22, 2014
I'm sorry, but I found this book to be terribly boring and not very informative. In a deeply ironic way, the book seems to share the predicament of the failed software project it describes: it keeps on meandering without getting anywhere. I kept hoping for some turning point or climax, but instead it just sort of petered out into nothingness.
May 17, 2018
Very well written book with some insights into the difficulty of creating large complex programs.
September 13, 2012
I was told that this book should be interested to just about anybody. I would edit that to say that it should be interesting to just about anybody who is interested in software more generally. I think I got a lot out of it because I am actually developing software, but the language is non-jargony and the stories are great for getting a sense of the history of programming.
Favorite bits:
"Time really does seem to behave differently around the act of making software. When things go well, you can lose track of passing hours in a state psychologists call "flow." When things go badly, you get stuck, frozen between dimensions, unable to move or see a way forward. Either way, you've left the clock far behind. You're on software time." -pg. 4
"It's difficult not to have a love/hate relationship with computer programming if you have any relationship with it at all." -pg. 5
"Their work is one percent inspiration, the rest sweat-drenched detective work; products are never finished or perfect, just varying degrees of "less broken." -pg. 10
"Adding manpower to a late software project makes it later." -pg.17
"…each time you add a new member to a team, the veterans must drop what they are doing to bring the latecomer up to speed, and everyone needs to pause to reapportion their tasks to give the newcomer something to do." -pg. 18
"much of the work in creating software also suffers from 'sequential constraints' that limit how far you can go in splitting up tasks: One task must be completed before the next can be tackled." -pg. 18
"Proponents of open source like to draw the distinction between 'free as in free beer' and 'free as in free speech:' Not all open source software products cost nothing, but all open source software is fee to be examined, adapted, and reused." -pg. 22
"Perhaps the idealist most programmers shear is a direct consequence of the toil and frustration of programming. If you're going to have to wrestle with daunting abstractions or squash armies of bugs, big ambitions can help pull you through the slog." -pg.22
Linus Torvalds: "In science, the whole system builds on people looking at other people's results and building on top of them. In witchcraft, someone had a small secret and guarded it–but never allowed others to really understand it and build on it. Traditional software is like witchcraft. In history, witchcraft just died out. The same will happen in software. When problems get serious enough, you can't have one person or one company guarding the secrets. You have to have everybody share the knowledge." -pg.41
"To Engelbart, bootstrapping meant 'an improving of the improvement process.'" -pg. 44
"Each computer-based advance in human productivity or convenience or creativity seems to call forth a shadow; our dreams of progress are troubled by crashes and viruses and spam." -pg.47
"If programmers paid too close attention to the legacy of software disasters past, nothing would ever get coded. The likelihood of failure would be too daunting." -pg.53
"'All programmers are optimists,' Frederic Brooks once write in 1975. 'Perhaps the hundreds of nitty frustrations drive away all but those who habitually focus on the end goal. Perhaps it is merely that computers are young, programmers are younger, and the young are always optimists.'" -pg. 53
"If you want to change the world…you need pessimism of the intellect, optimism of the will." - Antonio Gramsci pg. 54
"When we move some aspect on our lives into software code, it's easy to be seduced by novel possibilities while we overlook how much we may be giving up." -pg.57
"'Good programmers know what to write,' Eric Raymond had written in 'The Cathedral and the Bazaar. 'Great ones know what to rewrite (and reuse)'" -pg.60
"For programmers, just as for writers and artists and everyone whose work involves starting with a blank slate, the 'funnest' time of a project often falls at the very beginning, when worlds of giddy possibility lie open, and before painful compromises have shut any doors." -pg.64
"Just as dogs often come to resemble their owners, it seems that programming languages end up reflecting the temperaments and personalities of their creators in some subtle way." -pg.72
"Front ends are supposed to be elegant, intuitive, versatile; back ends are supposed to be invisible, efficient, rock-solid. The front end talks to people; the back end talks to bits." -pg.86
"'most programmers like to program. Some of them would rather program than eat or bathe.. Most of them would much rather cut code than chase documentation or search catalogs to try to figure out some other stupid programmer's idiotic work…Other things being equal, programmers design and build from scratch rather than recycle'" -pg. 98 (Larry Constantine)
- Stories behind name of Yahoo and Spam
"Here is one of the paradoxes of the reusable software dream that programmers keep rediscovering: There is almost always something you can pull off the shelf that will satisfy many of your needs. But usually the parts of what you need done that your off-the-shelf code won't handle are the very parts that make your new project different, unique, innovative–and they're why you're building it in the first place." -pg. 102
"There's an old saying: I can make it for you fast, cheap, or good. Pick any two." -pg.119
"One great irony inherent in the management of software projects is that despite the digital precision of the materials programmers work with the enterprise of writing software is uniquely resistant to measurement." -pg.126
"There is no reliable relationship between the volume of code produced and then state of completion of a program, its quality, or its ultimate value to a user" -pg.127
"Whatever the cause of the rising autism rates–whether Silicon Valley is conducting a vast experiment by inbreeding geeks or unrelated factors are responsible–there is something unsettling about the parallels between the autistic profile and the geek personality." -pg.134
"A celebrated…bit of graffiti from MIT captures this: 'I would rather write programs to help me write programs than write programs.'" -pg.142
"'The question is,' said Mitch Kapor, deep in the middle of a long meeting in a series of long meetings, "How do we sequence things to avoid spending an infinite amount of time before anything useful happens?' 'It's only infinite of you're stuck in a loop,' Hertzfeld replied." -pg.152
"In the annals of software history, Chandler's disappointing pace is not the exception but the norm. In this field, the record suggests that each driver finds a different way to run off the road, but sooner or later nearly all of them end up in a ditch." -pg. 173
"Don't expect me to get anywhere big in any kind of short time frame. I've been doing Linux for thirteen years, and I expect to do it for quite some time still. If I had expected to do something that big, I'd never have started." -pg. 174 (Torvalds)
"The spec is a programmer's bible, and, typical, the programmer is a fundamentalist." -pg.181
"Everybody who has success, especially when it's young, wonders: Was it luck, or was it skill? Well, it's a little of both. If you can do another really great one, it shows the world something." -pg. 207
"dogfooding…had the more modest and pragmatic aim of speeding up bug-finding and big-fixing by shoving developed' noses into their products' flaws." -pg. 209
"When people ask for numbers that far out, the traditional thing that engineers do is make them up." -pg. 219
"programmers are like carpenters or stonemasons–stewards of a body of knowledge gained by experience and passed along by tradition and apprenticeship." -pg. 250 (Brian Hayes)
"The real goal of a methodology is to sell books, not to actually solve anybody's problem." -pg. 257 (Joel Spolsky)
"Software developers are frequently portrayed as foot soldiers on death marches in pitched corporate battles. They take on missions and struggle to accomplish them under rapidly shifting circumstances and fog-of-war-style visibility. And they frequently develop that combination of fatalism and perseverance that has marked battlefield veterans throughout history." pg. 259
"Where you find software success stories, you invariably find people who are good at saying no." -pg. 260
"Flexibility is overrated. Constraints are liberating." -pg. 262 (DHH)
"To believe that we already know all the possible uses for software is to assume that the programs we already possess satisfy all our needs and that people are going to stop seeking something better." -pg. 266
"The 'great shame of computer science' is that, even as hardware speeds up, software fails to improve." -pg. 291
"Of all the things you can spend a lot of money on, the only things you expect to fail frequently are software and medicine." -pg. 292 (Jaron Lanier)
"That little drama is repeated again and again for each of us. We relive the whole history of computer science in our own lives and educations. We start off writing little programs–'Hello World' or whatever it might be. Everyone has a wonderful experience. They start to love computers. They've done some little thing that's just marvelous." -pg. 294
"The road to wisdom?–Well, its plain/and simple to express:/Err/and err/and err again/but lesss/and less/and less." - Piet Hein (pg 306).
"It always takes longer than you expect, even when you take into account Hofstadter's Law." - Hofstadter's law. pg. 331
"When people ask me when something will be finished, I respond, 'It will be ready sooner if you help.'" - Richard Stallman pg. 333
"Software development lacks one key element–an understanding of what it means to be 'Done.'" -pg. 337 (Alan Cooper)
"In the short term we always underestimate how hard things are, but in the long term we underestimate how big changes are." -pg. 353 (Ray Kurzweil)
Favorite bits:
"Time really does seem to behave differently around the act of making software. When things go well, you can lose track of passing hours in a state psychologists call "flow." When things go badly, you get stuck, frozen between dimensions, unable to move or see a way forward. Either way, you've left the clock far behind. You're on software time." -pg. 4
"It's difficult not to have a love/hate relationship with computer programming if you have any relationship with it at all." -pg. 5
"Their work is one percent inspiration, the rest sweat-drenched detective work; products are never finished or perfect, just varying degrees of "less broken." -pg. 10
"Adding manpower to a late software project makes it later." -pg.17
"…each time you add a new member to a team, the veterans must drop what they are doing to bring the latecomer up to speed, and everyone needs to pause to reapportion their tasks to give the newcomer something to do." -pg. 18
"much of the work in creating software also suffers from 'sequential constraints' that limit how far you can go in splitting up tasks: One task must be completed before the next can be tackled." -pg. 18
"Proponents of open source like to draw the distinction between 'free as in free beer' and 'free as in free speech:' Not all open source software products cost nothing, but all open source software is fee to be examined, adapted, and reused." -pg. 22
"Perhaps the idealist most programmers shear is a direct consequence of the toil and frustration of programming. If you're going to have to wrestle with daunting abstractions or squash armies of bugs, big ambitions can help pull you through the slog." -pg.22
Linus Torvalds: "In science, the whole system builds on people looking at other people's results and building on top of them. In witchcraft, someone had a small secret and guarded it–but never allowed others to really understand it and build on it. Traditional software is like witchcraft. In history, witchcraft just died out. The same will happen in software. When problems get serious enough, you can't have one person or one company guarding the secrets. You have to have everybody share the knowledge." -pg.41
"To Engelbart, bootstrapping meant 'an improving of the improvement process.'" -pg. 44
"Each computer-based advance in human productivity or convenience or creativity seems to call forth a shadow; our dreams of progress are troubled by crashes and viruses and spam." -pg.47
"If programmers paid too close attention to the legacy of software disasters past, nothing would ever get coded. The likelihood of failure would be too daunting." -pg.53
"'All programmers are optimists,' Frederic Brooks once write in 1975. 'Perhaps the hundreds of nitty frustrations drive away all but those who habitually focus on the end goal. Perhaps it is merely that computers are young, programmers are younger, and the young are always optimists.'" -pg. 53
"If you want to change the world…you need pessimism of the intellect, optimism of the will." - Antonio Gramsci pg. 54
"When we move some aspect on our lives into software code, it's easy to be seduced by novel possibilities while we overlook how much we may be giving up." -pg.57
"'Good programmers know what to write,' Eric Raymond had written in 'The Cathedral and the Bazaar. 'Great ones know what to rewrite (and reuse)'" -pg.60
"For programmers, just as for writers and artists and everyone whose work involves starting with a blank slate, the 'funnest' time of a project often falls at the very beginning, when worlds of giddy possibility lie open, and before painful compromises have shut any doors." -pg.64
"Just as dogs often come to resemble their owners, it seems that programming languages end up reflecting the temperaments and personalities of their creators in some subtle way." -pg.72
"Front ends are supposed to be elegant, intuitive, versatile; back ends are supposed to be invisible, efficient, rock-solid. The front end talks to people; the back end talks to bits." -pg.86
"'most programmers like to program. Some of them would rather program than eat or bathe.. Most of them would much rather cut code than chase documentation or search catalogs to try to figure out some other stupid programmer's idiotic work…Other things being equal, programmers design and build from scratch rather than recycle'" -pg. 98 (Larry Constantine)
- Stories behind name of Yahoo and Spam
"Here is one of the paradoxes of the reusable software dream that programmers keep rediscovering: There is almost always something you can pull off the shelf that will satisfy many of your needs. But usually the parts of what you need done that your off-the-shelf code won't handle are the very parts that make your new project different, unique, innovative–and they're why you're building it in the first place." -pg. 102
"There's an old saying: I can make it for you fast, cheap, or good. Pick any two." -pg.119
"One great irony inherent in the management of software projects is that despite the digital precision of the materials programmers work with the enterprise of writing software is uniquely resistant to measurement." -pg.126
"There is no reliable relationship between the volume of code produced and then state of completion of a program, its quality, or its ultimate value to a user" -pg.127
"Whatever the cause of the rising autism rates–whether Silicon Valley is conducting a vast experiment by inbreeding geeks or unrelated factors are responsible–there is something unsettling about the parallels between the autistic profile and the geek personality." -pg.134
"A celebrated…bit of graffiti from MIT captures this: 'I would rather write programs to help me write programs than write programs.'" -pg.142
"'The question is,' said Mitch Kapor, deep in the middle of a long meeting in a series of long meetings, "How do we sequence things to avoid spending an infinite amount of time before anything useful happens?' 'It's only infinite of you're stuck in a loop,' Hertzfeld replied." -pg.152
"In the annals of software history, Chandler's disappointing pace is not the exception but the norm. In this field, the record suggests that each driver finds a different way to run off the road, but sooner or later nearly all of them end up in a ditch." -pg. 173
"Don't expect me to get anywhere big in any kind of short time frame. I've been doing Linux for thirteen years, and I expect to do it for quite some time still. If I had expected to do something that big, I'd never have started." -pg. 174 (Torvalds)
"The spec is a programmer's bible, and, typical, the programmer is a fundamentalist." -pg.181
"Everybody who has success, especially when it's young, wonders: Was it luck, or was it skill? Well, it's a little of both. If you can do another really great one, it shows the world something." -pg. 207
"dogfooding…had the more modest and pragmatic aim of speeding up bug-finding and big-fixing by shoving developed' noses into their products' flaws." -pg. 209
"When people ask for numbers that far out, the traditional thing that engineers do is make them up." -pg. 219
"programmers are like carpenters or stonemasons–stewards of a body of knowledge gained by experience and passed along by tradition and apprenticeship." -pg. 250 (Brian Hayes)
"The real goal of a methodology is to sell books, not to actually solve anybody's problem." -pg. 257 (Joel Spolsky)
"Software developers are frequently portrayed as foot soldiers on death marches in pitched corporate battles. They take on missions and struggle to accomplish them under rapidly shifting circumstances and fog-of-war-style visibility. And they frequently develop that combination of fatalism and perseverance that has marked battlefield veterans throughout history." pg. 259
"Where you find software success stories, you invariably find people who are good at saying no." -pg. 260
"Flexibility is overrated. Constraints are liberating." -pg. 262 (DHH)
"To believe that we already know all the possible uses for software is to assume that the programs we already possess satisfy all our needs and that people are going to stop seeking something better." -pg. 266
"The 'great shame of computer science' is that, even as hardware speeds up, software fails to improve." -pg. 291
"Of all the things you can spend a lot of money on, the only things you expect to fail frequently are software and medicine." -pg. 292 (Jaron Lanier)
"That little drama is repeated again and again for each of us. We relive the whole history of computer science in our own lives and educations. We start off writing little programs–'Hello World' or whatever it might be. Everyone has a wonderful experience. They start to love computers. They've done some little thing that's just marvelous." -pg. 294
"The road to wisdom?–Well, its plain/and simple to express:/Err/and err/and err again/but lesss/and less/and less." - Piet Hein (pg 306).
"It always takes longer than you expect, even when you take into account Hofstadter's Law." - Hofstadter's law. pg. 331
"When people ask me when something will be finished, I respond, 'It will be ready sooner if you help.'" - Richard Stallman pg. 333
"Software development lacks one key element–an understanding of what it means to be 'Done.'" -pg. 337 (Alan Cooper)
"In the short term we always underestimate how hard things are, but in the long term we underestimate how big changes are." -pg. 353 (Ray Kurzweil)
December 26, 2023
In this book author describes the process of creating ambitious software application Chandler. This application was supposed to help people manage their emails, todo lists, calendars, meetings, etc. Chandler team wanted to develop best software which functionalities excel any existing PIM (Personal Information Manager). It would be open source and free (source code will be available for anyone, so users could make own changes in Chandler code too). Author accompanied software company for 3 years and finally published this book, when they still did not had first stable version of their product and there was still a lot of things to finish before there will have initial stable version. They finally released the software in 2008, after publication of this book and quickly abandoned it.
The story of Chandler development shows how not to design and create software. Chandler team got enormous resources and time to develop their dream software. They planned to create very big application from the start instead of creating MVP (Minimum viable product). They spend a lot of time on design and meetings before any coding work was done. They where ultra optimistic in terms of estimates for work to be done. They made many bad decisions, created own solutions for things which they could take of shelf, they spent a lot of time not working on Chandler, but on tools and placeholders for future features.
Most of the book content does not describe strictly Chandler development issues and progress. It looks that 2/3 of the book is about general issues which are common when developing software. There is some content about software development history and description of different concepts for the future of software development. A lot of space is used to describe the issues which programmers and managers face during such projects. The main point of this book is that making software is hard and often fails to meet expectations and software is rarely delivered on time and on budget. There are multiple reasons for it, both technical and human.
Many years has passed and many of the issues described here are still relevant. But there was small progress made in the following decade (author cites report from 2004). More software teams now use iterative approach to develop initial version of the software quickly and later improve it using user feedback, which gives better results than “waterfall” approach with no or very long iterations. Chaos report measures rate of success in IT projects and shows, that the rate of success slightly improved, but there are still a lot of challenged and failed projects. And I suspect that due to nature of software development and increased demand for software and human weaknesses, it will take long time to improve these statistics further (if it is still possible). As commonly mentioned in this book, Brook once wrote that there is no silver bullet for these issues. Data shows that despite measurable improvements when using Agile methodology, there are still a lot of failed and challenged projects which are Agile. Many things in software development are not easily to compare or measure, so a lot of different advocates (and sometimes cultist) still argue what is the best methodology/tool/framework etc. to do the job and I suspect that there will be probably no end to these arguments.
I work in software industry for many years and read The Mythical Man-Month before. If you read this book before and you know some stuff about software development history and software development issues, I suspect that you do not find a lot of interesting things here. This book also describes a lot of terms and processes during software developments. This was probably written in such way to make whole book more understandable for non programmers. I personally was a little bored when reading some parts of this book, probably because I was familiar with many of the concepts described here.
The story of Chandler development shows how not to design and create software. Chandler team got enormous resources and time to develop their dream software. They planned to create very big application from the start instead of creating MVP (Minimum viable product). They spend a lot of time on design and meetings before any coding work was done. They where ultra optimistic in terms of estimates for work to be done. They made many bad decisions, created own solutions for things which they could take of shelf, they spent a lot of time not working on Chandler, but on tools and placeholders for future features.
Most of the book content does not describe strictly Chandler development issues and progress. It looks that 2/3 of the book is about general issues which are common when developing software. There is some content about software development history and description of different concepts for the future of software development. A lot of space is used to describe the issues which programmers and managers face during such projects. The main point of this book is that making software is hard and often fails to meet expectations and software is rarely delivered on time and on budget. There are multiple reasons for it, both technical and human.
Many years has passed and many of the issues described here are still relevant. But there was small progress made in the following decade (author cites report from 2004). More software teams now use iterative approach to develop initial version of the software quickly and later improve it using user feedback, which gives better results than “waterfall” approach with no or very long iterations. Chaos report measures rate of success in IT projects and shows, that the rate of success slightly improved, but there are still a lot of challenged and failed projects. And I suspect that due to nature of software development and increased demand for software and human weaknesses, it will take long time to improve these statistics further (if it is still possible). As commonly mentioned in this book, Brook once wrote that there is no silver bullet for these issues. Data shows that despite measurable improvements when using Agile methodology, there are still a lot of failed and challenged projects which are Agile. Many things in software development are not easily to compare or measure, so a lot of different advocates (and sometimes cultist) still argue what is the best methodology/tool/framework etc. to do the job and I suspect that there will be probably no end to these arguments.
I work in software industry for many years and read The Mythical Man-Month before. If you read this book before and you know some stuff about software development history and software development issues, I suspect that you do not find a lot of interesting things here. This book also describes a lot of terms and processes during software developments. This was probably written in such way to make whole book more understandable for non programmers. I personally was a little bored when reading some parts of this book, probably because I was familiar with many of the concepts described here.
February 28, 2019
In my own quest to find interesting books that would help me understand my place as a software developer I've stumbled upon Dreaming in Code, something I knew nothing about other than it featured the word "code" in the title. It had to be good!
Book cover In the end the book surpassed my expectations by describing software from a totally different point of view than the programming books I am used to. Dreaming in Code is not a technical book. It can be read by software developers and bored housewives alike. It features a kind and professional tone and the three years of documenting the book can only help put the whole story in perspective.
The storyline is simple: a software visionary decides to start a new project, one that would be open source, innovative and revolutionary and also a replacement for slumbering Outlook and Exchange type of software. Scott Rosenberg documents the development process, trying to figure out the answer to the decades long question: why is software hard? What starts very ambitious, with no financial or time constraints, ends up taking more than three years to get to a reasonable 0.6 release, time when the book ends. The project is still ongoing. They make a lot of mistakes and change their design a lot, but they keep at it, trying to learn from errors and adapt to a constantly changing world.
For me that is both a source of inspiration and concern. If Americans with a long history of software spend millions of dollars and years to create a software that might just as well not work, what chance do I stand trying to figure out the same questions? On the other hand the spirit of the team is inspirational, they look like a bunch of heroes battling the boring and pointless world of software development I am used to. And of course, there is the little smugness "Hey, I would have done this better. Give a million dollars to a Romanian and he will build you anything within a month". The problem, of course, is when you try to hire two Romanians! :)
Anyway, I loved this book. It ended before it had any chance of getting boring, it detailed the quest of the developers while in the same time putting everything in the context of great software thinkers and innovators and explaining the origin and motivation behind the most common and taken for granted technologies and IT ideas. It is a must read for devs, IT managers and even people that try to understand programmers, like their wives.
Book cover In the end the book surpassed my expectations by describing software from a totally different point of view than the programming books I am used to. Dreaming in Code is not a technical book. It can be read by software developers and bored housewives alike. It features a kind and professional tone and the three years of documenting the book can only help put the whole story in perspective.
The storyline is simple: a software visionary decides to start a new project, one that would be open source, innovative and revolutionary and also a replacement for slumbering Outlook and Exchange type of software. Scott Rosenberg documents the development process, trying to figure out the answer to the decades long question: why is software hard? What starts very ambitious, with no financial or time constraints, ends up taking more than three years to get to a reasonable 0.6 release, time when the book ends. The project is still ongoing. They make a lot of mistakes and change their design a lot, but they keep at it, trying to learn from errors and adapt to a constantly changing world.
For me that is both a source of inspiration and concern. If Americans with a long history of software spend millions of dollars and years to create a software that might just as well not work, what chance do I stand trying to figure out the same questions? On the other hand the spirit of the team is inspirational, they look like a bunch of heroes battling the boring and pointless world of software development I am used to. And of course, there is the little smugness "Hey, I would have done this better. Give a million dollars to a Romanian and he will build you anything within a month". The problem, of course, is when you try to hire two Romanians! :)
Anyway, I loved this book. It ended before it had any chance of getting boring, it detailed the quest of the developers while in the same time putting everything in the context of great software thinkers and innovators and explaining the origin and motivation behind the most common and taken for granted technologies and IT ideas. It is a must read for devs, IT managers and even people that try to understand programmers, like their wives.
July 6, 2017
If there is only one thing I can to say about this book, then it is “This should be a must read for software developers, software product managers, and software engineering CS students.” Yes, it is that good.
The book chronicles the development of a personal information manager software named Chandler in early 2000. It does so in the light of how we view, have dealt, and are dealing with software engineering and its woes.
While it talks some about code, its narrative about people developing the software, people managing the development effort, and people leading the effort is as good as it gets in terms of portraying how real-world software development works — hard, fluid, broken, constantly being fixed, art, science. Yes, we have come a long way since 2004. Even so, many of the observations hold true even today.
Besides the chapters describing the development effort, few chapters (e.g., “methods” and “engineers and artists”) take pleasant, highly informative, and perception challenging detours into history of software engineering, pioneers’ view of software engineering, how we messed up, how we are messing up, and alternative views of how to “fix” software engineering. They consider views of diverse set of folks: Allan Kay (Smalltalk), Fred Brooks (mythical man month), Donald Knuth (TAoCP, TeX), Joel Spolsky (Joel on Software), Charles Simonyi (intentional programming), and Jaron Lanier (VR). These detours can really challenge the current perception of software engineering. If you have been in the trenches, then these detours will have your smirking and reinforcing your perception of software engineering :) All said, these chapters are alone worth reading the book.
Personally, I loved the book as it reinforced my reluctance to call software engineering an engineering discipline and my views about all the things we do right/wrong in the name of software engineering. I loved the historical and diverse perspectives on what is software engineering (or is it development?) and how should we approach it. Really got the rust of my wheels :)
The book chronicles the development of a personal information manager software named Chandler in early 2000. It does so in the light of how we view, have dealt, and are dealing with software engineering and its woes.
While it talks some about code, its narrative about people developing the software, people managing the development effort, and people leading the effort is as good as it gets in terms of portraying how real-world software development works — hard, fluid, broken, constantly being fixed, art, science. Yes, we have come a long way since 2004. Even so, many of the observations hold true even today.
Besides the chapters describing the development effort, few chapters (e.g., “methods” and “engineers and artists”) take pleasant, highly informative, and perception challenging detours into history of software engineering, pioneers’ view of software engineering, how we messed up, how we are messing up, and alternative views of how to “fix” software engineering. They consider views of diverse set of folks: Allan Kay (Smalltalk), Fred Brooks (mythical man month), Donald Knuth (TAoCP, TeX), Joel Spolsky (Joel on Software), Charles Simonyi (intentional programming), and Jaron Lanier (VR). These detours can really challenge the current perception of software engineering. If you have been in the trenches, then these detours will have your smirking and reinforcing your perception of software engineering :) All said, these chapters are alone worth reading the book.
Personally, I loved the book as it reinforced my reluctance to call software engineering an engineering discipline and my views about all the things we do right/wrong in the name of software engineering. I loved the historical and diverse perspectives on what is software engineering (or is it development?) and how should we approach it. Really got the rust of my wheels :)
March 7, 2017
This is a book about the creation of Chandler, an email/calendar/todo list that works on Windows, Mac, and Linux. It starts by talking about how Mitch Kapor came up with the idea for the product and decided to fund it as an open source project and takes it through three years of development. It does a good job of explaining technical decisions made along the way and capturing the spirit of a lot of hackers.
What the book is really about is why software is so hard. Time and time again the people on the project would dramatically underestimate the amount of time it would take to complete features – indeed, it took basically three years before they had a “dogfood” worthy release (one that they could use themselves everyday – this is known as “eating your own dogfood”). Because the scope of the project was so large to begin with, it took a long time to really nail down what it was going to do and how it was going to do it.
Software development is hard – very hard, and the book does a pretty good job of explaining why that is. The techniques that we have now work reasonably well for smallish projects but just aren’t very well suited for large ones. (see Virtual Case File, Windows Vista, etc.) This is not unlike when we first started building bridges – many collapsed due to poor design, but eventually we figured out how to do it well. Of course the problem with software is what the author dubs Rosenberg’s Law: “Software is easy to make, except when you want it to do something new.” and its corollary “the only software worth making is software that does something new.”
I enjoyed the book and suspect that even non-programmers would find it illuminating.
What the book is really about is why software is so hard. Time and time again the people on the project would dramatically underestimate the amount of time it would take to complete features – indeed, it took basically three years before they had a “dogfood” worthy release (one that they could use themselves everyday – this is known as “eating your own dogfood”). Because the scope of the project was so large to begin with, it took a long time to really nail down what it was going to do and how it was going to do it.
Software development is hard – very hard, and the book does a pretty good job of explaining why that is. The techniques that we have now work reasonably well for smallish projects but just aren’t very well suited for large ones. (see Virtual Case File, Windows Vista, etc.) This is not unlike when we first started building bridges – many collapsed due to poor design, but eventually we figured out how to do it well. Of course the problem with software is what the author dubs Rosenberg’s Law: “Software is easy to make, except when you want it to do something new.” and its corollary “the only software worth making is software that does something new.”
I enjoyed the book and suspect that even non-programmers would find it illuminating.
January 25, 2021
An informative investigation into the life of one software project (Chandler at the Open Source Applications Foundation), written in a lively form of an autoethnographic study. Contains a plethora of digressions into the historical and practical topics, explaining theories of programming paradigms, notable figures in history of computing and the practices of software production which are as relevant today as they were over a decade ago when the book came out. All of these components come together to confirm the underlying rationale of the volume, the problem of software complexity: "Our civilization runs on software. Yet the art of creating software continues to be a dark mystery, even to the experts. Never in history have we depended so completely on a product that so few know how to make well."
November 22, 2017
Making software is hard. That was the general conclusion by the time the book was written in the mid 2000. And now I can testify that it is still hard.
Reading this book is like opening a time capsule. Given the benefit of hindsight, it is now clear that the solution that they were chasing is easier solved infra-structurally (a comprehensive PIM application vs web-based/cloud/smartphone app): sharing, interconnectivity of different domains like calendar, todo entries, etc can now easily achieved by importing/exporting json file between apps of the corresponding domain locally or in the cloud.
But I also realise that someone has to make a bet. Even loosing ones. Because that is how we learn.
Reading this book is like opening a time capsule. Given the benefit of hindsight, it is now clear that the solution that they were chasing is easier solved infra-structurally (a comprehensive PIM application vs web-based/cloud/smartphone app): sharing, interconnectivity of different domains like calendar, todo entries, etc can now easily achieved by importing/exporting json file between apps of the corresponding domain locally or in the cloud.
But I also realise that someone has to make a bet. Even loosing ones. Because that is how we learn.
November 25, 2017
Great exposition on the Chandler team, regarding a specific project, as well as software in general. Didn't check the final mix, but it was feeling like the project was only about a third of the material.
Great references too, from Kay and Lanier, to the coining of Software Engineering and its first conferences. The issues of scale, the comparisons to other disciplines and art vs science.
Whilst it instantiates many instances of pain as the team slip backwards and sideways on their grand vision - or, hell, on just getting any software further advanced and written - it is often inspiring, aided by the discussions with either those on the team or outside it musing on their passions and thoughts and ideals.
Great references too, from Kay and Lanier, to the coining of Software Engineering and its first conferences. The issues of scale, the comparisons to other disciplines and art vs science.
Whilst it instantiates many instances of pain as the team slip backwards and sideways on their grand vision - or, hell, on just getting any software further advanced and written - it is often inspiring, aided by the discussions with either those on the team or outside it musing on their passions and thoughts and ideals.
Displaying 1 - 30 of 243 reviews