I took Managing Iterative Software Development Projects, by Kurt Bittner and Ian Spence (Addison-Wesley, 2007, 672pp, $49.99, ISBN-10: 0-321-26889-X) home to read over the Memorial Day weekend, and curled up with it on the couch Saturday. My 13-year-old daughter asked what I was reading, so I held it up to show her. "Managing Iterative Software Development Projects?" "Yes." "And you're reading it strai “Managing Iterative Software Development Projects?”“Yes.”“And you’re reading it straight through?” “Yes.”“That’s sick.”“Sick” can be taken a number of ways coming from her, but based on her tone of voice I don’t think it was a compliment. To be fair to myself, a science fiction novel and the latest issue of The New Yorker were also on my reading pile at the time. Reading this book reminded me of why I have always practiced iterative, incremental software development: it’s because I was trained as a physicist, not a computer scientist. My formative programming efforts (in the 1960s and 70s) were subservient to mathematical and scientific goals, so I almost automatically fell into a pattern of applying the scientific method to programming: hypothesis, experiment, conclusion, revised hypothesis… I would start with a clear goal for an iteration, and clear criteria for determining whether the program was operating correctly. The source code I wrote became the hypothesis, and running the test cases the experiment.Computer Science was an emerging discipline at the time. When I was a Physics graduate student at Brown in the 1970s, computer science was taught out of the Applied Mathematics department; now, of course, it is a thriving department in its own right. I taught computer science courses at the Boston University Corporate Education Center for several years in the early 1990s; I have never actually taken a computer science course.But back to Managing Iterative Software Development Projects. I found this book valuable, in that it crystallized a lot of practices that I’d learned from decades of trial and error experience. Why tackle the hardest parts of a project in an early iteration? Bittner and Spence make it explicit in Chapter 1: you do proof of concepts early to reduce your development risk. Why give the customer frequent builds to review? To reduce requirements misunderstandings early. It was a holiday weekend, so I didn’t finish the entire book: the temptation was too great to start reading the science fiction novel on my pile, and once I started that I was loath to put it down. It’s Eifelheim, by Michael Flynn, and I’m not surprised to find that it was nominated for a Hugo award this spring.I usually like to read physical books, but you can also read parts of Managing Iterative Software Development Projects for free online at Google and Addison-Wesley and Safari. You can also read all of this book and other Addison-Wesley and O’Reilly books online with a monthly Safari subscription. Software Development