Testing Times

I'm an Extreme Programmer, no make that a Goddam EXTREEEEEEEME Programmer. Yee haw. etc.

'Extreme Programming', for those of you who don't know seems to stand for, 'Extreme-ly sensible combination of the last thirty years lessons in software development. Programming'. Fortunately, it's got a catchy and GODDAM EXTREEEEEME marketing name, otherwise y'know it might sound a little dull.

What it boils down to are a few sensible principles designed for building software, rather than trying to crowbar software into a system used to make bridges or circuits (ie Software Engineering).

The principles are:

Test First, Code Second - AKA Test Driven Development. Simple one this, all programmers want to get stuff working as the first thing they do. And the second. And the third. Pretty soon you've got a very complex system going, at which point it starts to break. And you fix it. And it breaks somewhere else. Bums. If only you'd written some tests to check the code was working. You can't do it now, where would you start? So you fall back on a combination of manual testing, and crossing fingers.

Test driven development demands that you write the tests a little at a time, for a bit of code before you code it. This makes you nicely disciplined into doing it, and gives you a great batch of tests that'll tell you if your new changes have broken anything. Believe me, this is a great relief. As a nice side effect, structuring code to be testable generally forces you to have a clean design.

Keep it simple - Only write the code you need to pass the tests. If you need more code, write more tests. This saves you writing code to solve problems you might never come across.

50% now is better than 100% never - Get something working as quickly as possible. Use placeholders, simplification, whatever, just get it playing. This way you can see if it's any good as quickly as possible, and you haven't wasted effort over-desiging something you're about to ditch.

The design is wrong and the customer is right - And if you've got something working, get players to play it, see if it's what they want, and if not, change it. Do not have a fixed plan for your destination or you may end up building a lovely white-elelephant that nobody wants to play.

Two heads are better - Get two people to work together on everything. This not only reduces bugs by about 60-odd percent, it also stops you wandering off down pointless paths and lets you bounce ideas off your partner. Ideally, one of you writes a test and the other implements the code (then vice versa) so you don't prejudice the implementation. I'm obviously not going to do this, because there's only me.