In last 5 years of Software development, I have always seen that almost invariably, the endgame of the project is the one which pains the most. Here are few of the things that I have been observing which went wrong in the project.
- Long Project lifecycle – Project life-cycle is too long. Its a already 4 months just the build (post design). This is taking toll on the team since the team is tired of looking at the same code and keep tweaking it.
- Perpetual Requirement changes – The long life-cycle of build phase has allowed customer to have sufficient time to see what was wrong in the current requirements. He is anxious to provide the updates to requirement so that its more useful. He would love to see the changes incorporated in the current build cycle itself. On the contrary, developers (and the manager/tech lead as well) are wary of any such changes since such changes often are not thought through and create more instability than value-add.
- Incremental resource loading – Addition of people in phases does hell lot bad to the project. (We added 3 people in the project almost one month after initial increment of 3 people was done). If you want the team to deliver the best, get everyone on the board at the start (need not be at the start of requirement) but at least at the start of design.
- Why one time resource loading? – For the initial team, inclusive of existing and the new, we had had a very detailed (almost like 15 sessions) walkthrough the requirements and the initial application framework design. It also gave chance to everyone (both new and experienced) to play around the app design to get the feel of it and press out any issues in the design. It also jelled that part of the team pretty good. Come one month down the line 3 new people, everyone is head over heals into their own functionality design and development, no-one is really paying attention to get these 3 people going. So ultimately these 3 people lose out on the great experience of playing with the framework. They also do not get basic requirement contexts as no-one has chit-chatted the requirements with them.
- Biggest failure of incremental resource loading – I did not realize it then, but it was extremely advantageous to the project that I returned from onsite for the design phase. I could relate the offshore team with the requirements in a better fashion since I took the requirements hands-on and had a business context of the complete requirement. I was knowing the answer to eternal ‘WHY’ of many many smallest requirements. I was knowing the background of any particular requirement as to why the requirement so. But to the new 3 people, there was no time for sharing these tidbits of the requirements. Lesson: Get whoever you want at the start and give them a ground up.
- Automation – Unit Testing – Despite my being supportive of it, I failed to make customer believe in advantages gained out of automated testing. We failed by telling the customers that it would take 1/3 the time of total build effort to create and maintain testcases for the application. It was probably a decent estimate of the effort, but what it hides is confidence that can be built due to the automated testing combined with continuous integration process. No customer would say yes to such addition to the project effort (and money) unless he/she sees the advantages that are gained out of it. How I wish, I should have had detailed discussion with my customer to buy his confidence then.
- Automation – Web Application Testing – Since Unit Testing provides you with just that – ‘a unit’ test, we need something which will smoke test the application end-to-end lets say, every 2 hours. This would have created a hell lot confidence in the working of my application. There are many tools which can help here. Commercial as well as free / open source. Rational Function Tester is a promising tool. So is open source tools like Sahi, Selenium and Canoo Webtest. As unfortunate as it is, I seem have not vested time in any one if it anytime. I must do that to find out which one is better than the rest and then make my customer and team use it.
- Lack of coherent requirement documentation – With a big showoff inside the company and also at customer location, we created multitudinous requirement artifacts viz. a usecase document, a ppt showing the part-by-part details of the screen and its possible changes in various flows, minutes of meeting with customer as well as with other application teams, and a mind blowing application look-a-like html clickable mockup. Amazing huh? I am still impressed with my own creation. But with so many artifacts, am now stuck with non-searchable subversion repository of all these artifacts. Now I feel the need of a wiki like structure which would be search-able, navigable, editable by everyone in the project (inclusive of customer!). It would have been so cool in the offshore scenario. Wiki would have kept the revision history, it would have just sufficed one single page for the things covered in usecase as well as things covered in ppt.
- Continuous Integration – Now that customer is changing the requirements frequently when he sees the application previews, I have started to see the correctness of points raised by Martin Fowler. He argues in favor of continuous integration that, if there had been automated testing and hourly build process setup, the team would have been so confident of the build that is been created that it wouldnt have bothered the team about changes in requirements. I admit, whenever I get a change in requirement, I wince and try to find out as many faults in the requirement. [Anyways, sometimes it necessary to do just that in order to get the complete requirement.]
- Agile Test Driven Development – The project with huge complexity like my current project, it would have helped to create a smaller development cycles with smaller and incremental goals. The agile mantra would have been perfect: You build some, you test some and you show some to customer. Again here, even though I am sold to this idea a long long time ago, I failed to make it believable to both my customer and my company. We could have taken a smaller (but COMPLETE) set of goals in hand and implemented them. Based on the success of them, we could have put on additional features. But this did not go down really well with my company and my customers. I also did not press a lot.
- Archaic Technology – All the technology that we use in the current project is something that was published at least 4 years ago. So in order to add the cooler features of web2.0 world today, it takes lot of pain with those old technologies which were never created for such task. Next project I must ensure that I start off with the latest versions of best tools of the market today.
Phew thats a lot of junk I managed in one project! So, does that mean this project is basically a big failure? 
I am kind of undecided on it right now. I agree that we messed up on lot of stuff but I also see that we still have managed to pull it off so far! With all the gems that constitute my team, I am very proud of my team and has belief that we will pull it through.
Amen!
VJ
