Iterative Development – there is a simpler way to work - Part I

NOTE: This text (part I and part II) is just an introduction to the existence of an alternative, not a guide to use that alternative.

Probably the only way you know when you want to start a new project (for college for example), is the famous Waterfall mode. That's (Planning,Analysis,Design,Implementation,Testing).
When ever you get a project idea that you like and want to start in, your first thought is to gather all your team* to start doing the analysis.

You would probably be happy when you finish your analysis document(s). But now you want to do the design (most probably you understand design as "UML Class Diagram" only).
So you put the analysis documents aside, and perhaps this time let each team member tries to figure out the classes of some part of the project.

So far, although that it contains a handful of mistakes, the life is smiling at you. But...

Once you finished the so called "class diagram", you start the implementation. Needless to say, you will end up probably nothing like the design, that's if you were lucky and your project isn't really a very complex one.

And because you end up with something different, i.e. changes are added randomly as you find them, the code complexity will increase, readability will decrease, lots of ad-hoc fixes**, and will take much longer than anticipated to get it to work as you wanted (and with high probability you will miss the dead-line, and deliver your project nonfunctional or with lots of bugs that makes it totally unusable).

Well, this mostly isn't really because you are bad, or you did something wrong. But this is due to the nature of both the Waterfall model, and your experience in the kind of project you are trying to do. I will explain.

The Waterfall model assumes that you know exactly what you are doing, and that's there will be no modifications -in the design- afterwards. To do that, you must have tried and did that -arguably exact- kind of projects several times before. Which in an academic settings is not always true; because in each subject you are assigned a project to apply what you've just learned. So the uncertainty factor is very high. Thus the Waterfall assumption fails, and now it is to hinder you more than to help you.

Fortunately, there is an alternative way that assumes the uncertainty and will help you in that regard; Iterative Development***.

I will talk in details about it in Part II isA.

* This in the context of under-graduate projects' teams in our faculty.
** For people who don't know what ad-hoc means, I quote from some of my friends ;) = "طلسأ طلسأ يا عم الحج". See it on wikipedia http://en.wikipedia.org/wiki/Ad_hoc . In Arabic it probably means اعتباطاً. It's not always bad in some conditions, but in programming, it usually is.
*** Iterative Development isn't a model or process by itself but it describes a feature of several different processes. Like -for example, not to list- the Rational Unified Process, Extreme Programming, SCRUM, and generally the agile software development frameworks, all of which, is beyond the scope of this text. This text is just an introduction to the existence of an alternative, not a guide to use it. If you were interested to use it, you should pursue a good book or a good reference in that regard.