Baby steps towards agile development 001:

spaghetti1) Quality

Disclaimer: This stuff applies 99% of the time.

You can’t exhibit agility in your software development if you write poor quality code. The same goes for tests (maybe I’d better make that step 1.5!).

A primary facet of agile software development is the agility to change direction quickly. You can’t do this when change is too expensive. Poor quality code makes extension difficult and therefore costly. Poor quality code makes refactoring very difficult, and therefore costly. Poor quality code can make automation harder (we’ll get to that later), and therefore costly.

Poor quality code can also make it more difficult to ensure that you have working software as much as possible (it’s often good to be able to demonstrate what you’ve got so far to the client, and to get feedback based on that). Your team should all be familiar with, and understand SOLID principles & the benefits of their appropriate application.

1.5) Unit Tests

Disclaimer: This stuff applies 99% of the time.

I shouldn’t really have to say this, but… Write tests! and make sure they’re good ones. You can’t refactor fearlessly without a comprehensive set of automated unit tests, as a minimum, functioning as a safety net.

The agility to change rapidly means the agility to refactor without fear. You ideally need tests to cover every required unit of functionality, and those tests need to be good quality tests – poor tests are worse than no tests as they cause fear, uncertainty & doubt. At best, poor tests are an unnecessary maintenance cost – often they are far more dangerous in the way that they mislead.

A Test Driven approach to development (TDD) is often ideal – done correctly you should only ever have code that has a specific reason to live, and that code will be written in a testable way, and will be tested out of the box.

You should never need to go to bed at night worrying whether you’ve broken something!

Bearing in mind that unit tests constitute a maintenance cost, there can be such a thing as too many tests (as well as overly fragile tests, etc, which I won’t go into here) – something I’ve heard referred to as ‘TDD OCD’. For example, if a particular ‘unit’ of functionality has no branching logic, then it does not need it’s own test – it is perfectly acceptable to test that unit indirectly as part of another, broader test.

See http://osherove.com for some good unit testing resources.

If you don’t have good  test coverage (and by that I mean that you actually test – rather than just cover) then you are almost certainly not going to be agile in any meaningful sense of the word.

Imagine an acrobat – with a safety net he can show off his amazing agility to it’s fullest, and should he fall he can simply climb back up the ladder and try again. Without a safety  net he might show amazing agility right until he falls and dies. Development without such a safety net is equally reckless, and in reality that means that any real agility will not be realised, due to  fear.

This entry was posted in coding, software. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s