Interesting read. I find the analogy extremely fun to read but purely anecdotal. I think most would agree after reading this analogy that iterating faster accomplishes more work over time, if it works for F86s why not software right? If find it no different than saying working faster (acting faster) accomplishes more in a shorter period of time. I’m sorry but DUH!
The real question is why if a team does approximately the same amount of total work, how does the duration of an iteration effect the ultimate timeline when the same amount of total work needs to be accomplished? While most agree that an iteration can be too long, could it also be argued that an iteration is too short thus negatively impacting the duration of a project?
It goes without mention that iterative development incurs overhead. The overhead consists of planning each time, delivery/deployment each time, etc. The more interations you have the more overhead is incurred. So why is iterative development so hailed?
Enter parallel processing. Given a fixed amount of work to be completed the fastest (from a time perspective) way to complete that work is to have work performed in parallel as much as is reasonable. Reasonable meaning that doing things in parallel makes sense up to the point where the cost of overhead starts to outweight the benefit of parallel processing. Iterative development like parallel processing sacrifices efficiency for better utilization.
Ever worked on a puzzle? Yes those antiquated cardboard pieces that are put together to form a picture. If you have one person working on the puzzle they will do and X amount of work. If you have two people work on the same puzzle they will do X+O(verhead) amount of work, why? Simple, I’ve worked on a puzzle before with someone and have had to hunt for a piece that I had seen before. After a few moments of not finding it I ask the other person, have you seen that piece, it was right there a minute ago. They respond yes it’s over here, I’m trying to see if it fits in this area. Though we’re now doing more work, we also have twice as many people doing the work in parallel which shrinks the duration. Now extrapolate this to three, four or more people. Eventually depending on the size of the puzzle adding more people would actually increase the duration as we’d be bumping into one another.
The main difference with a software project/puzzle is that not everyone is performing the same function. There are architects, developers, testers, etc. No matter how hard you try you can’t always work in parallel as some things are sequential/serial in nature. This is true even for the puzzle example but to a lesser degree. Regardless, the name of the game is to increase the parallelism (minimize the serialization) as much as possible even though you incur overhead in doing so. Given a fixed team size (processors) and fixed amount work to be completed how can a team increase the parallelism of their work? Simple, interations… Why have a tester sitting there doing nothing until all development is complete why not chunk the work up so the tester can test what is ready. Same type of examples can be drawn up for business anlaysts, business stakeholders, customers, etc. They key is add some overhead in the form of more frequent comunnications, hand-offs, deliverables, deployments, etc. also known as iterative development so more people/processors have greater utilization.
The end result is NOT
- Working faster
- Working less
- Working more efficiently
Rather the end result is:
- Working more, with less inactive time
- Reduced duration (THE ULTIMATE GOAL)
- Working less efficiently as you have introduced overhead.
So rather than Boyd’s law of iteration (which is merely an anecdote) the real reason for this cause and effect has to do with Amdahl’s Law: http://en.wikipedia.org/wiki/Amdahl’s_Law of parallel processing. This can explain both having to few processors (long interations) and to many processors (extremely short interations) for a given amount of work. No doubt Amdahl’s law and my pathetic puzzle analogy is more boring than the fighter plane analogy. Personally I’d rather associate with fighter aces but the analogy unfortunately doesn’t explain what’s really going on. It’s very inspirational however and the masses prefer a good story. I tip my hat for the creative story. Well done!