Iterative Design

When you are dealing with large amounts of requirements, it is never easy to think about all the possibilities at one time. The design process works a lot better when smaller chunks are handled independently. It is a good trend to do things iteratively. However the art of iterations, is not a science in itself. Having iterations does not mean you are automatically doing it right.
There are many ways to iterate with different durations and you need to choose the best one for you and your team and the task at hand. 

Some misconceptions of iterative design need to be addressed.

* Simply using an iterative approach should make us better (fallacy - there is more to it)
* Iterations are a set length (fallacy - they should not be)

We do things in iterations, so I will skip to next chapter
Unfortunately, the term "iterative" is a victom of its own success. It has been around for so long, in so many industries, it makes sense on so many levels, that many take it for face value.
For example the term can be applied within and surrounding product life-cycles, and it can be differently applied to each phaze within a cycle differently. Consider Iterative Design Vs Iterative Development. Now think about the title of this entry. Iterative Design

Now that we have established I am purely talking about Design, read on.

A set duration should not be applied to all iterations 

In larger teams, where there are many designers working on many segments, you have to coordinate the iterations so they line up. Also by consequence, the iterations tend to be larger. As an example, I have found on average, larger projects experience 4-8 weeks of design and implementation as an iteration.
In smaller teams, you can find an iteration as small as 1-3 weeks. You will also find it harder to secure iterations with respect to testing and proving the iterations works. Larger teams can afford to incorporate resources that test iterations. The length of a duration therefore also depends on the amount to test.
You need to have iterations that vary according to the task at hand. You cannot fix an iteration as a policy only a guideline. It must be agile.

However, let's focus on Design.

Designing in iterations does pose some questions. Should I design, implement and then design again? What if I change something that affects everything? Do I have to think of everything now? How can we design everything up front without spending too much time on it? Design can last forever, when do you draw the line?

Design to Implement

In software, we have an incredible advantage over other industries. Design can be implemented and then refactored, and continuously moulded. The building industry would have a hard time dealing with this kind of change. (I have some experience, having been on building sites, drawn architectural and surveyors drawings, filed for permits and seen regulations, and measured apartment blocks) The building industry (by my experience) hates change. We can and should love it. 

When I was involved with AutoCad and MicroStation, and Drawing offices where getting more and more computers, many mistakenly thought that suddenly drawings would be quicker and easier. However, the truth goes for nearly everything in computing. It makes things easier for 'Change' not neccesarily for 'Creation'. (With Software Factories and other new and exciting things, this will change - [see what I did there?])
Software allows us, to change things, shake it up, correct mistakes. There is a balance, refactoring too much can take a lot of time and be a costly exercise.

Design can be done in chunks and evolved. The key to designing in iterations is to make sure you leave extension points or hotspots, and to make sure you design the core things first.

Get your hands dirty

Another aspect to iterative design is hands on experience. A designer has to provide more input into implementations and actually get involved. This is where larger teams sometimes fall short. The larger team, who has an architect who gets his hands dirty will be in a far better position to make a success of their design. No matter the size, architects must code and be involved. They must see and experience each iteration and fine tune it, while in it. They are (or should be) the most experienced and most wide thinking people.  

There are some distinct advantages:
 - The duration of a iteration can be adjusted by the Design who sees it happening
 - The implementation idioms can be pushed back into the design if required
 - Knowledge from developers within the implementation can bubble up into the design (often)
 - The Designer can get ideas and fine-tune things in his mind, by looking and seeing what works and what doesn't

Lastly a word on how to design in iterations:

A good design should be fairly abstract in early iterations becoming more refined over each consecutive iterations. This is to reduce refactoring (as it is time consuming), and to provide less chance of error. If requirements are discovered with each iteration, it should be used as a refinement of the initial abstraction and generalized design, rather than a change in the entire design.

I will post on the following topics soon:
DesignAbstraction first then DesignRefinement

[Last updated: 21-10-2007]