I have been talking with various leads and managers across my practice to understand what seems to be the reason behind the delay in the delivery of projects. I work in a testing major area as a developer in test and I just wanted to understand why there seems to be an ever increasing number of delivery failures and delays? Well there are lots of reasons
1) Not following iterative model
2) Not working closely and getting immediate feedback from the clients.
3) Too much emphasis on unnecessary and bulky process instead of delivering value
4) Too much emphasis on fancy frameworks
4) But an oft missed point is final dash to integration.
It is normal for me to work in a testing alone project, where the regression test scripts for an application are built by the team. This post is for teams who work on such projects though the general principle also applies to the whole development community.
Whenever I meet a lead of a team confident of his project success, the first question I ask them is how often they integrate and run their scripts. Their answer always seems to be we have a well defined process, a time tested framework and coding standards. Let the boys concentrate on coding now. We don’t need to worry about the integration now. We will do it before we deliver. But every time I see them struggling with the code base to glue it together to make sense out of it. Haven’t we all learned the lessons that even if we have the best process in the world, differences however subtle can disrupt it and make us scurry to find the cause? Haven’t we learned that if we don’t do something we can’t be confident of it?
Even if we follow all the best practices (Personally I don’t believe practices are context dependent) in the world in the team, there are differences in way which each person would work. As well without constant feedback that what we are doing individually works together as a single entity, there is no way we can march forward towards deadline. Integrating early and often is the only option we have in projects and it need not be only development teams but also teams creating testing code. It eliminates the doubt and risk of hassles during the delivery as well helps us to deliver on demand. Whenever during the day a piece of task is complete, integrate with the existing testing code base and run it against the application. Most of the existing continuous integration servers help you to do the task. Even if you work on purely automated testing projects which I do sometime, opt for continuous integration to see if the scripts or code you are writing can work together and not just as individual modules in developer’s machine. Using continuous integration also helps us to run the scripts in a standardized environment rather than individual ones. It also helps to catch the failures that may happen when someone’s code broke another person’s work which won’t be possible in the last minute integration.
There would be an overhead of an integration machine and build scripts which the testing team would normally not prefer. But it comes at the advantage of giving us feedback about the project’s health, eliminating the big bang integration at delivery and helping us to eliminate the errors and differences as soon as possible. When you make integration a non event, it will be surprising to find how easy it is to deliver the code without hassles.
If you want to know more about continuous integration, you can get more info from the article by Martin Fowler http://martinfowler.com/articles/continuousIntegration.html.
Also there is a book Continuous Integration, Improving software quality and reducing risk by Paul Duvall.