1.4. Iterative Processes

Have you worked at a company that only performed employee performance reviews yearly? I'm sure most developers have, but during the yearly review have you had a manager say, "On June 13, 2008, you forgot to shut off the kanooter value, and every Friday since then you have not been shutting it off!" or something similar? I'm sure many developers have been in this situation. If the manager had indicated that you were doing something wrong you could have taken measures to correct the issue. This same paradigm happens with software development. Project managers spend a great deal of time working with customers to define exactly what a piece of software should accomplish. However, it's common to find that after the project manager has completed collecting the requirements for an application, the customer doesn't see the application again until development is "finished." This is the reason many software projects fail. In the last few years, Agile Software Development processes have became very popular among developers. One of the key principles in Agile Software processes is iterative development.

Iterative development groups the development of new features together and delivers small chunks of a project to a client, rather than waiting a long time to deliver a very large monolithic system. Agile teams try to keep the iteration period low, perhaps two weeks to a month, and at the end of the iteration they always have something to show. Some attribute the success of Agile to short iterations and constant communication with clients.

Agile developers and managers often speak about reducing the cost of change. Cost of change simply put is this: the longer it takes you to find a defect the more expensive it will be to fix. The cost of change topic is discussed heavily in the project management world; some attribute low cost of change to a very close feedback loop with customers, managers, and developers.

Testing suites can provide many entry points for gaining different types of feedback. At a very low level, testing provides feedback from the code itself about its current state and whether or not it is working correctly. At higher levels, acceptance testing gives developers feedback if the system was developed to specification.