Programming in iterations is something that has always made sense to me at some level. If nothing else, I like seeing the change logs for each version of a program. But in the last few months I've had the idea on my mind quite a bit. I feel that my paradigm for programming is shifting.
It probably started when I got my new job and they kept asking about Agile development experience. Then later we had a week of official Agile training. I'd also been reading The Mythical Man-Month. Then the other day I also read a Coding Horror post about the same subject.
The main idea is that through iterative methods, software "grows" or "evolves". This is in contrast to the idea of "building" or "constructing" software.
As Mr. Brooks points out in his book, the analogy of "building" software is very compelling and can be very useful. It captures a lot of the careful planning and execution required when writing code. It also serves as a great metaphor as to why things are never just a "simple matter of programming".
But the building analogy falls short in many ways. It really fails to capture the mutable nature of programming. Code is not etched into stone tablets. It can be modified and bent to the will of the programmer as easily as I typed this post. Also, unlike a well designed and constructed building, you really never know if you've been building the software correctly until you've already done a good share of the work.
The emerging paradigm of "evolving" software seems a better fit. Like a plant, there are detailed structures and processes which go into programming. At each stage you can see gradual improvement. Each version or revision is the "offspring" of the one before. Good adaptations are kept while old or bad ones wither away.
This evolutionary process is driven by code changes made by programmers. A bug is fixed here, a new feature added there. Small tweaks are made all along the way. The skill set and demeanor of a successful programmer resembles a craftsman. He is a creative explorer rather than an assembly line worker.
It just makes sense to me. Iterative programming seems to have much better balance between documentation, planning, designing, and coding. You do enough of each of these to get to your current goal. Then you focus on the next step, the next feature, the next idea. Instead of getting lost in the pie-in-the-sky dreams, you're actually building your way to them. Of course, this means you have to be ready and willing to enter a chrysalis from time to time in order to change both inside and out.
I'm excited to see how iterative programming plays out in my own projects, at work, and in the industry in general.
