Wednesday, 8 February 2012

We're doing Agile, right?

Agile Software Development has taken off big time: it appears on every one's CV, you can do M.Sc's in it, all the cool guys are into Agile. And we're doing it too.


Agile cover a multitude of methodologies but I'll stick to one of the first formalisations: Extreme Programming or XP. This made a number of trade offs: you don't have to do A because you're doing B which will cover the same ground. The obvious side effect is that if you're not doing B you're in trouble.

Let's look at some concrete examples. Programmers like to program so the release from large scale up front design is often welcomed. Up front design is used in waterfall development to ensure that the group know what they're all trying to build an that the final product has a suitable architecture for the task at hand. So how does XP (or any other Agile approach) handle this?


Don't Repeat Yourself. If you see a piece of duplicate functionality, factor it out. This provides a retrospective design to your software. But wait, changing software is dangerous so you'll need

Comprehensive Test Suite

With good test coverage there's little risk involved in modifying code and if you do something stupid there's always your buddy to fall back on.

Pair Programming

Let some one else look at the code you're writing. They'll pick up mistakes you've made, point you at other bits of the system that look similar and be some else to fix the bugs whilst you're on holiday.

The important thing to notice is that all the pieces are entwined. If you don't refactor the code you'll end up with spaghetti code because you didn't do big up front design. If you don't have comprehensive test suites your refactoring will break things. If you don't pair program or code review then, in the absence of design documentation how does the system architecture get communicated?

Agile development is a high discipline approach to software development. It forgoes some of the safety nets of traditional software development and instead utilises other practices in an attempt to improve development efficiency. If you ignore the replacement practices you've no longer got a safety net and you're just hacking at code till it sort of works.

No comments:

Post a Comment