keep repeating this cycle until we have implemented the most complicated part of the technology, and the product has sufficient features to make this technology attractive to the user. At this point, iterations are a matter of days.
After we release a 1.0 version of a product, our users often offer many useful ideas about product features and functionality. Generally, our technologies are right on target, but our presentation of the technologies could be enhanced to better meet user needs. Because of the sheer amount of feedback we receive at this point, we cannot implement all the good ideas in a single short cycle. Instead, we respond to this feedback over a period of time. We collect this information, turn it into feature requests, and then enter these requests into our bug-tracking system. Next, we prioritize the features and decide which ones will be implemented in which subsequent releases. These features are then implemented incrementally throughout the next series of releases. Here, we are using an incremental model because although we know which features we need to implement, we are not certain how they should be implemented.
Once we have completed a number of releases, we gain a deep understanding of the market and the users' needs. We understand the technology, have flushed the previously unknown aspects of the technology, and do not need to perform the extensive amounts of research that we did in the earlier stages of the project. After we achieve this understanding, we shift to a waterfall process, where the cycle for each release typically spans about six to eight months. At this point, the waterfall process works well because we can define the work that needs to be done up front, we really understand the code structure and layout, and we can foresee how new features need to be built.
In the ideal world, all developers would master all development processes so that they could easily determine when another practice would help them, then execute the appropriate practice flawlessly. In reality, it's actually not that difficult to master a variety of different development processes. After all, you've probably noticed that the three major development processes share the same four fundamental phases: design, implementation, integration, and testing. The main differences between these three processes are the length of the phases and the features implemented in each phase.
If you get a good grasp on each of these four common phases and what practices can be applied to improve and expedite each one, you will have the skills required to execute these phases independently of length. In any process, you need to integrate practices into these four phases that will prevent errors from destroying your process and the software it produces. Once you're able to do this, you should be able to work effectively within any of the main development paradigms.






