Thoughts on software development from a software engineering manager and perpetual student.

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.

No.

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?

DRY

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.