Agile Development

The past year or so I’ve been interested in the various facets of Agile Development. The best place for someone to start looking into with respect to agile development is the Agile Manifesto. In my own words, I would say agile development is about embracing change and developing software in such a way as to be able to deal with changing user requirements.

Traditionally this has not been supported by the software lifecycle models. Traditionally, at the start of a project a requirements document is created through meetings and analysis between domain experts (possibly the client) and requirements engineers. Once this set of requirements is perfected the system is designed. (this is often referred to as Big Design Up From (BDUF)). Once the design is perfected, implementation begins. Different parts of the system may be distributed to different developers or development teams. Once every part of the system is implemented, they are all pulled together and integrated. Finally the entire system is tested, issues are fixed, and the product is released. The usual response to a change in requirements in this situation would be for someone to stamp his foot down and shout ‘requirements are not supposed to change’ and then blame the analysts for not doing their work correctly. However, the fact of the matter is that requirements do change and the challenge for developers becomes, ‘How can we develop software in such a way that we can respond to changing requirements and maintain a high quality product which is of value to a customer?’. Martin fowler has written a very good essay talking about why the traditional software development lifecycle is unsuited for most real world projects.

Now one of the main points of being agile, and permitting large code changes while maintaining quality and not introducing bugs is to test the software. A lot. Throughout the software development process. And to have automatically running tests that cover as much if not all of the code. However, this is not always easy. A class will depend on another class which will depend on another, which will depend on another. It is very possible there are cases that are really difficult to test. (example of untestable code). So one of the sessions I went to talked about ‘Designing for Testability’ by Roy Osherove. Primarily guidance was given in what to test and how to test it.