Matisse has an interesting post, Software is like Building Construction. He talks about iterative design and the interdependencies of people with deliverables as being common to construction and software.

In my opinion, he’s not all wrong, but he’s not all right. I agree that there are plenty of design-build firms who wait until the last possible moment to cement the design before building. When we remodeled our house, we used an iterative process, and yes, we incorporated the things we’d learned from earlier in the project to the later phases.

But the place where I believe the metaphor falls down is the cementing of design and the use of people. In construction, plumbers don’t do electricity, electricians don’t do carpentry, and none of tradespeople do any top-level design. (The general contractor might, but not the individual plumber or electrician.) In reality, in software projects, any developer can (and does) change the top-level design if things don’t fit. The top-level design does not have to be finalized–ever. In fact, the more releases of a software product, the less some level of design is cemented or finalized. And, effective software people know a lot about the rest of the product, not their small piece.

Construction projects can learn from software and software projects can learn from construction. But to me they are very different in nature and the metaphor does not work as a whole.

Read The Graphing Calculator Story. (Thank you to Obie Fernandez for finding this gem.

Some ideas that stood out for me:

• The secret to programming is not intelligence, though of course that helps. It is not hard work or experience, though they help, too. The secret to programming is having smart friends.
• …he told his manager that he would start reporting to me. She didn’t ask who I was and let him keep his office and badge. In turn, I told people that I was reporting to him. Since that left no managers in the loop, we had no meetings and could be extremely productive.
• we needed professional quality assurance (QA), the difficult and time-consuming testing that would show us the design flaws and implementation bugs we couldn’t see in our own work. [...] One guy had a Ph.D. in mathematics; the other had previously written mathematical software himself.
• … my sanity was saved by the kindness of a stranger (there are several stories of people who helped in various ways)
• Sitting behind a one-way mirror, watching first-time users struggle with our software, reminded me that programmers are the least qualified people to design software for novices.
• Dozens of people collaborated spontaneously, motivated by loyalty, friendship, or the love of craftsmanship.

When I’ve written about canceled projects in the past, I’ve recommended that managers not allow skunkworks projects like this to continue, because there is too much drag on the organization. However, for this project, the drag appears to have been minimal — but I’m not sure. Can you say that your project is composed of people who collaborate, are internally motivated to create something wonderful? If not, do you know what you could do to move the project staff towards that frame of mind?