Iterative Development – there is a simpler way to work - Part II (finale)

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.

Because I -personally- believe that an example is worth a thousand words, I will tell you my personal experience with iterative development; the story of our graduation project. We only tried iterative development when other ways failed.

Our graduation project was a clustered server for massive multiplayer online games. The entire period for the project to come out was approximately 10 months, overlapping an academic year.

We've spent almost 9 months of them in the design phase; the project turned out to be very big and needed some research and novel techniques. For 5-members team who doesn't know anything about clustering we needed that much time.

Anyways, having only one month left to hand the project, there was no single line of code. We thought that we already have an exhaustive list of classes and functions and it's only a matter of implementation.

Trying to implement the classes we designed, we had no idea how to start, and just -exactly- after 4 functions we totally lost contact with the design and didn't know how to proceed. We were overwhelmed by the complexity and inter-dependencies between modules that it was NOT possible to see anything running before at least thousands of lines of code, which will need even more time to fix (cuz they were not tested).

That seemed inappropriate for the 1-month due time. Our main problem was the inter-dependencies of the modules. That's where iterative development kicked in. (Note that changes in the server and the game affect each others so they have to be done according to each-other step by step).

You will notice in the following sequence that at any point of time we could
A. Hand something that worked, not complete, but works.
B. Features are added incrementally. That means at the dead line we will have N features working, compared to a complete set of features that doesn't work at all.

1- The ping server
The first thing we did is to implement a simple server and test if the game (which was not practically a game then :D) can connect and exchange messages with it. - day 1

2- Simple actions
Then we implemented simple actions to make the game work and players interact - the server is not clustered and there is no state persistence or anything. - day 3
(Starting from here, the server development and game development was going in parallel)

A. Server development

3- Splitting the server
After that we implemented a simple layer above Java Remote Method Invocation (RMI) to be able to split the server on the set of computers in the clusters, and to make debugging easier (that layer could be disabled to run the whole server on a single machine). - day 9

4- Persisting the state
Also, we've developed something we called Object Store to provide transparent persistence using aspect oriented programming. - day 26

5- Work that was not complete until we handed the project
Proper Object Store synchronization between several machines, database replication, security checks, traffic control and traffic load balancing, server peer to peer load balancing, distributed administration.

B. Game development

3- Adding a few actions each day to extend the things the player can do. First walking, then attacking, then riding a car etc. (That's very simple view, the actual actions are numerous and much more complicated than that). - Until we handed the project

Conclusion:
Using iterative development, we've faced the overwhelm we had from the extreme complexity and actually delivered something that was working and people can actually play and enjoy. Compared to waterfall model, nothing would have been delivered in the deadline, and there would have been an implementation paralysis, and an elongated testing phase which might require lots of parts to be reimplemented too.

It's like splitting a big project into smaller projects with limited set of features, and doing that over and over until it's enough or you meet the deadline.

Pros:
Early feedback
More visibility, for the developer and for the client, the client can make changes early (cuz client don't know what they want !
Can deliver at any point of time

Cons:
Adding new features later can result in modifying existing code or removing it, which is the cost tradeoff of using iterative development