Recently I've been reading Dreaming in Code, which is billed as "the first true successor to Tracy Kidder's Soul of a New Machine."  I really enjoyed Soul of a New Machine, so I figured I couldn't miss with Dreaming in Code.

 

Both are written in the same style, with a relatively non-technical author watching and writing about a group developing a product; the main difference is that Soul concerns a hardware project (Data General's first 32-bit machine) while Dreaming is about a software project--namely Mitch Kapor's open-source Chandler PIM.

 

For what it's worth, I enjoyed Soul of a New Machine more than Dreaming in Code.  It might be because the former was about hardware development, something I'm not familiar with.  But I think more likely it's because at the end of Soul, they actually had a solid, finished computer whereas at the end of Dreaming, they had (at best) a buggy, slow, barely useful piece of software.

 

Regardless, one positive aspect of Dreaming in Code was that it touched on several topics on which I have strong opinions, so it was a good catalyst for me to revisit how software could be built better.  So, hopefully over the next week or so I'll post a few entries giving my take on what was presented in the book.

 

First up:  Software development processes.

 

What's funny is that I bet if you spoke to most people I've worked with, they'd say, "Oh yeah, Ben, he hates any formal development methodologies!"  But that's really not the case at all--conversely, I'm convinced that process is a huge key to building better software faster and cheaper.  The problem that I see is that most of the development processes out there tend to do the opposite--they slow down the development cycle while not improving the quality, features, or performance of the software being developed.

 

Don't believe me?  How many times have you heard a discussion about software process where someone says, "we need to make sure that we don't start skipping the process when crunch time comes"?  Whenever I hear that, I see a huge red flag going up--why would someone skip the process in order to get something done faster?  Wasn't that the purpose of the process in the first place?

 

For example, Henry Ford brought the concept of the assembly line to auto production in order to improve the speed and consistency of building cars.  I can't believe that if the Ford factory was struggling to meet production numbers, the workers would start saying, "wow, this assembly line idea is stupid!  I'm just going to start building cars one at a time like we used to, because it's faster."  Instead, everyone quickly realized that the assembly line was a far superior way to build cars, and to do anything else would slow them down.

 

Yet the opposite is the norm in the software world.  People are resigned to thinking that all development processes invariably slow down the development cycle, with the benefit of some esoteric payoff at some point in the distant future.  This drives me absolutely nuts--a good process should speed up the development process, with obvious payoffs in a relatively short timeframe (days or weeks, not years).  Anything else is doomed to fail.