I have recently been working on a classic ‘nightmare’ project… it had no specification, several different developers had worked on it, the requirements and goal posts were constantly moving and the killer… it had massive integration with other services (it involved around 37 individual services using over 20 tables to work in harmony for the whole thing to work)
http://jondjones.com/wp-content/uploads/2013/06/bannercodetutorial.jpg 456 1595 Jon D Jones http://jondjones.com/wp-content/uploads/2013/04/logo.png Jon D Jones2012-06-04 20:46:382016-01-27 16:39:09Why Phased Integration is BAD
I was given a task to simply copy one chunk of code into another service… simple. However, that one simple change turned into then just doing another ‘quick’ integration with another service, that involved re-writing a different service, that involved revising how the system stored the data, then another subsection needed to be re-written to work for a new business requirement and then… well you get the point.
For each requirement change, the time estimate changed and when my boss asked me when it would be finished, how could I answer ? The only option to turn this project around was to change my approach; after all the definition of insanity is doing the same thing over and over and expecting different results, right ?
While I was working on this project, I also happened to read the chapter in Code Complete about phased integration and my current situation could not have been a better case study about why phased integrations never work. A phased integration, in case you do not know, is when all the different parts of a system are built separately and then all of them are combined at the end in the brave hope it will seemly just work in harmony.. the normal result is that some idiot (me in this case) spends weeks or months constantly plying whack-a-mole bug fixing until it does what it says on the tin.
My solution to the problem was to negotiate with the project lead to start stripping out functionality and phase it in smaller chunks. The big advantage with this approach was that the business could start benefitting straight away; for him it allowed him to be able to track progress and it also made for more robust code as it was released sooner and bug tested quicker.
So my advice to anyone reading this.. if you EVER find yourself unlucky enough to be in the same situation on a project, your best bet is avoid phased integrations, scale down the functionality creep and deliver, test, then release the smallest of functionality as you can get away with. If you’re brought in halfway through a project don’t try and be stubborn and continue down the path blindly just to prove you can do something, start stripping down your requirements. Client are much happier if you can deliver something of value NOW over promising an all singing and dancing version at some unknown point in time… maybe ?