One of the signs of increasing age in the IT industry is that of ‘déjà vu’. New things that are laboriously explained to you ring all sorts of bells. The past flashes before one’s eyes.

I visited a company developing Internet-based applications the other day. They were proud of their progressiveness and explained to me that they developed database systems using the radical new Agile XP (Extreme Programming) methodology. Wow, I thought. That must have impressed the shareholders. Perhaps they don’t realize that Agile XP is known in the industry as ‘Cowboy Coding’.

I feigned ignorance, which is not usually hard for me to do.

‘Well,’ said my genial and pleasant host, ‘one of the great things about Agile XP is that one tests every part of your code as soon as you’ve written it and you don’t go on to the next bit until it has been thoroughly tested. Flaws in the system are easily communicated by writing a unit test that proves a certain piece of code will break.’

‘Gosh! You mean you test your code rather than just write it?’.

‘Ingenious isn’t it. When writing code, the unit test provides direct feedback as to how the system reacts to the changes one has made. If, for instance, the changes affect a part of the system that is not in the scope of the programmer who made them, that programmer will not notice the flaw. There is a large chance that this bug will appear when the system is in production.’

‘Funny how nobody has ever thought of this before.’ My face goes red when I’m desperately trying to stop myself guffawing with laughter. What I love best about working in IT is its rich unintended comedy. My host misunderstood my visceral difficulties as excitement

‘Because you can never be certain that what you coded is what you meant XP uses what it calls ‘Unit Tests’. These are automated tests that test the code. The programmer will try to write as many tests he or she can think of that might break the code he or she is writing; if all tests run successfully then the coding is complete, and the programmer can then go on to develop more code.’

My eyes bulged. My face flushed red.

Seeing how interested I was he proudly produced an elaborate Java-based module he’d written that provided a test harness for SQL queries and procedure. ‘It is great, you can change the parameters in the query (Klop Klop Klop on the keyboard) just type in what results you expect’, (Klop Klop Klop Klop), ‘and then Run the test harness’ (Klop Klop Klop Klop Klop Klop)

Various windows flashed on the screen in front of me, full of inscrutable commands. It was all very ‘Seventies’.

Finally a message popped up from the depths saying ‘OK’. He was so proud; it could have been his baby.

‘Look, all we have to do is to change SQL code a bit in order to simulate an error and you’ll see what happens!’

(Klop Klop Klop Klop Klop Klop)

Wow. An error message popped up saying there was an error in the code.

‘To think that, for all these years, we’ve been doing it so stupidly’ I sighed, shaking my head in mock-regret. I’m afraid I wasn’t able to show him the way that a SQL Programmer like myself would go around doing the same thing in their humble rudimentary way. I hope I explained enough to suggest that that perhaps there has been some sort of primitive thought before the genesis of Agile XP.

Before you write code, you write a test-harness. (it is often best to get someone else to do it, preferably someone with malice in their soul). When you write the piece of SQL code, such as a function, you append the test harness for unit-testing purposes. In some places I’ve worked, you’d be given a rough time at code-review if these were missing or inadequate. Here is an example…. (normally, you comment out the test harness when the code is ‘put to bed’ and the GO moved to the end, so that the harness stays with the code, or you can, in SQL Server, save it as an extended property.)

There are many cleverer ways of doing it but I blush to think of the stupid bugs that this sort of system catches, that slip through casual testing.