Metaflex

When I was studying Information Technology I was taught the classic Systems Development Life Cycle. Since then I have been exposed to many more development models and strategies and have come to the conclusion that each project is different and will require a different approach.

It is also easy to see when the development process is being done wrong. At least I think it is easy to see, but that could be hindsight as it is always trickier to get your foresight to work. Let me tell you about the development cycle at a local outsourcing firm that I am unfortunately being exposed to.

The development models in use

At its heart the development models in use are the Iterative model, Evolutionary Prototyping , and a bit of Verification and Validation. None of these are wrong or bad, but the project is still struggling due in part to how these models are being managed and a large part to how the project was started.

The problems

The system’s presumed function and audience has changed dramatically during the first few months of development and all of the original coding was done by a junior programmer. I know he is a junior programmer as I can see novice mistakes in the code. His mistakes include not understanding how Object Oriented programming should work, his user interface design, and his approach to handling data for a web based interface. They all scream inexperience and haste. If this was to be a throw-away prototype, a once-off proof of concept, then it would be fine. It could even be a growth experience for the junior programmer as someone more experienced could criticize the code and everyone would learn. That was not the development model that was chosen though.

Remember the Evolutionary Prototyping model in use for this project? Well its aim is “to build a very robust prototype in a structured manner and constantly refine it.” Which means that this pile of amateurish code is now the foundation for all iterations of development. There is also no convincing the boss that a rewrite is in order as the client has already paid a lot of money and they can’t be expected to pay again.

The end result is that any change to the system – new feature, bug fix or performance enhancement – is very likely to break another part of the system. This makes maintenance tricky and deliverables difficult to promise.

How could this mess have been avoided? (mostly anyway)

The original system could have been thrown away and the client’s requirements could have shaped the next version.
More experienced developers should have been brought on when the client was sold the idea.
User requirements should have been managed more clearly and in a formal manner (this is a whole other problem that I didn’t even raise in this post.)

Will these lessons be learned?

I hope so.