There are many practices in the Agile community, specially among XPers. Among those, TDD (test driven development), refactoring, and pair programming are other three most talked about practices aside from CI. Most of these practices have believers and non-believers.
TDD. Recently Uncle Bob preached TDD to all developers in his keynote speech at RailsConf 2009. Although I am a big fan of Uncle Bob and learned a lot from his writings over the years, I am afraid I have to side with DHH on this practice. Don't get me wrong. I like TDD, but I do not think it is a key to "clean code." Test first approach is not natural, it takes a lot of practice. Even then it may seem difficult to many developers. I am of the opinion that whether you write test first and then code or vice versa, you must write tests. But, follow what feels natural to you. That way you as a developer will have fun doing it. I agree with DHH that it is important that we have fun while writing clean codes. At the end, as a client/sponsor I do not care whether tests were written first or not, what matters is whether the software comes with comprehensive tests or not (code coverage). By the way, if you haven't seen Uncle Bob speak, you must. He is very animated speaker.
Refactoring. Although most projects/products go through refactoring at least once (if not more), it meets with resistance from all sides. Because, it comes with the connotations like low quality, incompetence, waste etc. Developers do not want to admit that their own codes need rework. The project managers do not want to ask clients to pay for something that is already done and working. The clients when hear "refactoring" becomes anxious thinking that the software that they are paying for is of low quality. The other end of the spectrum is teams can get overzealous and end up spending in this endless cycle of refactoring. So, it is difficult to implement "just enough" continuous refctoring that helps a team to maintain a sustainable forward pace on the project. When that right balance is struck, refactoring helps design to emerge/evolve as well as keep technical debt to a minimum.
Pair programing. One of the most controversial practices. I have to admit that I was a non-believer too until recently. My team has recently started doing pair programming and found it to be very helpful specially for refactoring type and complex works. It probably is not as effective for all types of work as well as every team. The most challenging aspect of adopting this practice is to justify upfront increased, however small or large, development costs and time and convince clients to pay for it. At least in the minds of clients, two persons working together on one thing at any time will look like they will be paying twice as much for the same amount of work and probably will take twice as long. It is a hard sell.
CI. It is the most accepted practice with very tangible benefits that both technical and non-technical persons can appreciate. If your team is not currently doing it, you should push for implementing CI immediately. If your team is already doing it, make sure you have the 10 elements mentioned in Martin Fowler's article. The diagram below shows the main steps involved in CI.
Most tools will generate Web reports and send email every time CI process runs. As a client, or PM, or manager, you would want to be on the distribution list for this report. Also you should learn how to read the report so that you understand what it means for your project. Even if you are not following Agile process, you can still benefit from CI.
No comments:
Post a Comment