7 - 1. Iterative Development

Main Points

• Philosophy of Iterative Development Iterative development is a process with a purpose.
• Iterative Methodology How iterative development works.
• Iterative Development Sample OK, so how do we do it?

If you've taken all the trouble to build your application right, why wouldn't you take advantage of it? If you've got good utility functions, why wouldn't you build additional functionality based on them? If it's easy to create new functionality because you've built key portions of them already, why wouldn't you extend the application? If you've written your application to save time under maintenance and modification, then why wouldn't you spend a little time there, you know, saving time? Especially when it's the most efficient way to turn out new functionality? These are key benefits of iterative development. It is a simple idea to help you start your next project, but chances are it will eat up the rest of your life exploring all the opportunities you have to improve on what you've built.

Philosophy of Iterative Development

Iterative development is a methodology. It's a process for getting things done, however iterative development is not a generalized process. There is a philosophy behind it. There are two main reasons why you would choose iterative development. First, if you have a dynamic application to support an organization's functions, then it makes sense to keep building it; continued development is an investment in the organization. You have to scale up to do the same things for more people. You have to diversify to offer new products and / or services. Scaling and diversification each require investments in the personnel, material, and / or technology to make it work. Given the economic shifts occurring in the early Information Era, technology and its ability to manage knowledge are a key investment for many organizations. That makes iterative development a major issue for maintaining your current technology resources, as well as to grow, expand, and branch out into new areas within your business plan.

Second, if you have a product that you want to provide as a business, that is best organized as an iterative development project. In order to continue your business over the long term, you need to continue to update the product so that current customers have a reason to continue to spend money on a product they believe in.

In short, iterative development is how you run a website or web application that's going to grow and thrive. If an application is not going to grow or expand, then there are a number of other alternatives to iterative development. You can put in place a solution and continue to use exactly that level of functionality for an indefinite period of time. In that case you have the option to purchase a 3rd party package or SaaS (software as a service), or even having a project written for you. Those aren't projects that are likely to be able to grow or interface with other solutions and so iterative development is not a requirement. However, anything that's going to need to evolve with you should be an iterative project, preferably one that is coded in house, if at all possible. This allows your team to learn the system thoroughly and be able to use it efficiently.

Iterative Methodology

Assuming that your project is going to grow and that your organization has decided to invest in its success, then iterative development is how you accomplish this goal. I discussed in project development the importance of major projects. While you don't want to lose track of important smaller items on the project list, it is far worse to become distracted by small projects. Large projects that have major functionality are the most important thing you can do to invest in your organization. However, in design and construction, I have repeatedly said that you want to work on small projects, because they're not only faster to accomplish due to the quantity of work... they are fundamentally easier to understand and that makes them qualitatively faster to write. So which is it? Should you work on small or large projects?

Iterative development is the process of having your cake and eating it too. In the 1960s, you accomplished this by ignoring the efficiencies of small projects and going after large projects; hundreds of developers spent years writing and debugging a piece of software. Today, using iterative methodologies, you can decompose a large project into modules. Each module can be decomposed into classes. Each class can be decomposed into data and functions, although at a level this low we're now talking about incremental development, breaking a single project into smaller pieces. Incremental development is iterative development's little sister. If incremental development is successful because it let's you break a single project up into smaller, more efficient pieces, iterative development is about breaking up your entire project list into smaller more efficient pieces.

During project development, I've noted that you create two lists. The first one is simple, you simply define your projects in order of value (though I will note here as well that value is based on the usefulness of the project divided by the time and resources needed for completion). The second list is where you decompose your big project into smaller projects and define your iterations.

Basically what happens is this. A big project takes a lot of time and effort. You would rather not embark on a project that large, incurring all the inefficiencies of doing so or devoting extra time to breaking the project down into smaller and smaller steps to gain those efficiencies. Further, many organizations simply do not have the option of making that large an investment and no matter how well decomposed, that's a long time to wait for results. Iterative development helps you identify overlapping functionality in different projects. This way you can work on related small projects, each of which takes a bite out of a big project. Under the right conditions, by the time you tackle your "large" project, you only need to extend your code base a modest amount to accomplish that goal; you've effectively turned your large project into a small one through iterations of the FSDLC. That's the secret of iterative development; you accomplish big goals and tackle big projects, you just do it one piece at a time.

Iterative Development Sample

So iterative development is about building your second list so that you can turn large projects into bite size pieces. That presumes we have a first project list to start with, so let me construct a realistic but hypothetical first project list that's organized only by project value. Then I can give you a quick demo of the effects of iterative development.

1. Project 1
   • Module 1
   • Module 2
   • Module 3
2. Project 2
   • Module 2
   • Module 4
   • Module 5
   • Module 6
   • Module 7
3. Project 3
   • Module 6
   • Module 8
   • Module 9
4. Project 4
   • Module 4
   • Module 6
   • Module 10

So I have four projects in this list which require a total of 10 modules. On one level, we could take the old fashioned approach, write all ten modules and then launch them live. However, then we're waiting around for a long time for that functionality to come about. At the very least, if we developed them starting at module 1 and working our way through 10, we'd have some functionality available after module three, more functionality after just four more modules, and then two more projects complete in the next three modules. Right now these projects are laid out in order of importance. However, you'll note that we can probably do much better.

Project 1 is our most important and requires three modules. Further, it only shares a module with one other project, project 2. That's no reason to shuffle anything ahead of project one (and we haven't even looked at how massive project 2 is which only makes a change even less of a good idea).

Project 2, however, is a pretty big one. It appears to have five modules, but look again. By the time we start project 2, we'll already have completed module 2 (it's necessary to complete project 1); that means we really only have four modules to build and maybe some modifications to module 2. Still that's a fair chunk of programming. We'd like to tear some work out of that if possible.

Project three does share a module (module 6) with it, but that's not going to be a big deal unless module 6 is an especially large risk in the project. Assuming it is, we "might" consider it; we'll have to weigh the importance of project 2 (which encourages us to hammer out project 2 first) vs. the riskiness of module 6 (which encourages us to take on the smaller project 3 first). This could be a tough call.

For now, we should just note that module 6 does indeed look risky and there's an argument to be made for prioritizing project 3 before project 2 and keep looking. We'll make a more definite decision later. Looking at project 4, we see that this has some key possibilities. Project 4 shares two modules with project 2 including the risky module 6. If we considered doing project 4 first, we could tackle writing it along with only two other modules. That's definitely an improvement over writing three other modules along with it. Also, only module 10 does not eliminate work from project 2.

Tackling project 4 first will reduce the size of our largest project to something much more manageable, we will take on our riskiest module with less work to do (fewer alternate modules) and we are not adding that much work to the completion of project two (we're taking on the one additional module 10). That's a distinct advantage so let's shuffle the project list and see what we've come up with.

1. Project 1
   • Module 1
   • Module 2
   • Module 3
2. Project 4
   • Module 4
   • Module 6*
   • Module 10
3. Project 2
   • Module 2
   • Module 4
   • Module 5
   • Module 6*
   • Module 7
4. Project 3
   • Module 6*
   • Module 8
   • Module 9

I've made the adjustments that we talked about (shuffling project order), starred the modules which involve significant risk (as in application killing / major redesign risk), and crossed off the modules which will already have been built by the time we begin construction on the project. Note that I have not deleted them, since there may be some modifications necessary to make the module work properly with the project. This is a relatively small change but let's take a look at the advantages.

We will still complete two projects by the time we've written seven modules – they'll just be projects 1 and 4 instead of 1 and 2. Moreover, project 2 will be finished in almost the same amount of time as before. We will need to construct eight modules to get it up and running instead of seven. That's really the only drawback. Moreover, we get a critical bonus. The risky module 6 is now loaded into a smaller project with only two other modules (instead of four). That will make developing module 6 much easier and increases both our chances of success and the speed with which we can complete development (especially if module 6 fails or requires major redesign). Further, if module 6 fails or changes significantly, we will know that project 2 can't be accomplished (at least not as designed) even before we begin the project. Risk management therefore is greatly improved by this new configuration. We can examine alternatives without writing lots of code that we might have to throw out.

Also note what's happened to our projects. Measuring the project in terms of modules completed is not really useful, since people are only going to care how much time it took to finish them. Project one and four will each require three modules to complete. However, in the process of building them, we will have finished three modules needed for project two. Aside from some modifications, our massive five module project will only require us to build two modules. From the standpoint of making our programs more understandable and therefore faster to write, we've eliminated our biggest challenge. Further, when we build the risky module 6 we won't be programming three other modules, but only two. That reduction could be the most significant time savings of all. That's the beauty of iterative development, and why it can help us to much more reasonably attack and complete our projects, and this is how I formally work iterative development into my project management plan.

One last point is worth making. The individual modules that we list do not have independently useful functions (otherwise they would have been broken out as separate one-module projects). Therefore, nothing that we've done suggests how we will construct the project or the order that we'll attack the modules in. That will only be determined when we complete the application design on each project and prioritize construction for incremental development. That's where we handle organizing the order of construction. The only thing we can say for sure at this point is that there is at least some portion of module 6 which is troublesome. Those risky classes, functions, or whatever else that's inside module 6 will most likely be prioritized pretty highly when we start on project 4. But we aren't terribly concerned about that right now; we'll work all that out later in the process.

I'm a big believer in iterative development. I look at the methodology as nothing less than taking advantage of the code you've already written. The inaccessibility of code that you've purchased is a huge disadvantage that I don't believe most organizations weigh with the proper seriousness. This effectively accepts that you're going to pay someone else for their code, but it's not worth as much as code you wrote yourself. That had better be "really" inexpensive code, that takes almost no time to set up, or you could be throwing away money hand over fist. Iterative development gives you customized power to do exactly what you want to do, and build on top of all the functionality that you already have. That's golden.