Fan Mail on Iterations and Increments

Hi Mary,

Thank you so much for your reply! Feedback from the experts on my writing really helps me to plug the holes and to soften the sharp edges (of which there are probably more than I dare to know).

After reading my latest article, you say you didn’t understand the difference between iterative development and incremental development as I wrote it. I think this difference was best described by Alistair Cockburn in several articles. One example is: “Incremental versus iterative development”.

He described (quite convincingly) that people should not do one without the other in a software project. I’m afraid I have not contributed anything to what has already been said by smarter people, other than having decorating the subject matter with silly jokes to make it a more pleasurable read. But I will make sure to reread my own article to see where I can improve on it, and beat Mr. Cockburn along the way.

Your example — where you compare programming to writing — is quite valid, but (in my humble opinion) incomplete. Writing is usually a solitary process, while programming often is not. I sometimes wished programming was a solitary business, because it might save me some headaches and despair. But, on the other hand, I would have to blame all the bugs on myself, so I don’t know which is worse.

Please allow me to alter your analogy slightly: suppose a team of writers was writing one book. Work (chapters) would be divided among the writers, and each writer would write and rewrite his own chapters until he was reasonably satisfied with them, before showing his results to the other writers in the team. That is what we called common sense until Martin Fowler came up with the silly but catchy name “refactoring”.

On the next (higher) level the book will gradually start to get its form. Here another cycle of improvement is taking place. The entire team will have to keep rewriting pieces of the book until style, plot and characters are consistent throughout the work. Probably the publisher’s editor will give feedback, which will usually also lead to some rewriting. We look at the book as a whole (preferably with someone who looks at it with a “reader’s eye”) and decide how it must be changed to make it better. That is what is usually called iterative development. Many industry experts think a rhythmic process works really well here. Of course, not doing it rhythmically is an option. But not doing it at all, is not an option. Note that, for my own book, I practice iterative development by sending individual chapters as articles to industry experts and buggering them until they reply with valuable feedback. It works amazingly well!

Finally, the book will be published in its first edition. Maybe the publisher decides to release the book as the first volume in a series. Or as a limited hardcover edition, a number of weeks before the softcover edition. In any case, the real users will start reading it (or not) and the market will give feedback on it. This will lead to revisions, a second enhanced edition, etc. For software developers that is incremental development. And the nice thing about most software is that, unlike book publishers, we can deliver as many new editions as we want. — Of course, having written only 60 pages of a 350-page book, I will be glad to reach that first edition at all, before collapsing from mental exhaustion.

Thanks for taking time to read my work. I really appreciate it.

Regards,
Jurgen Appelo