Tuesday, November 09, 2004

My first taste of dog food

I'm about to add a data import feature to Sydney. This might appear to be a bit premature since the main core of the system is nowhere near finished and, apart from a few flashing lights in my unit tests suite, Sydney doesn't really do anything useful yet. Why would I be writing the data import routine this early when the core is still unfinished and very likely subject to change?

The answer, of course, is that I'm looking to eat my own dog food as soon as possible.

I don't have the luxury of dedicated testers so I need to spend as much time making use of the system in the same way a future user would. By importing my large store of historical data into Sydney and managing it there on a day to day basis I'm hoping to identify problems now rather than at release time.

It will also give me plenty of testing data and I won't have to worry about converting test data as the data format changes. Instead I'll just clear out all the data and reimport again.

Since there is so much of the core application still to be written those import routines will likely be broken by changes several times over the coming months. This shouldn't be too big a deal though. As long as I fix the import routines each time they break the changes required shouldn't build up and become a major task. The time I lose making those fixes I should recover by having a more robust and well tested system that requires less debugging further down the track.

How will I know when changes to the core have broken the import routines?

Two ways. Before I even write the import routines I'll be writing some unit tests to check that the import routines will at least execute without error and perform some basic validation on the imported data. I execute all unit tests frequently as part of my development process so I should know almost immediately of any major errors that cause the import to fail.

Secondly I'm thinking of clearing out and then repeating the full import of all my historical data on a nightly basis. This will hopefully help me realise if more subtle errors have crept in, errors that don't cause the import to fail but perhaps affect the consistency of the data.

There's nothing revolutionary about any of this of course. I'm just making good use of some best practices and techniques I've learnt from others. You can read about Joel Spolsky's experiences with eating his own dog food and there's a wealth of material available on Unit Testing and Test Driven Development from the XP folks and others.


At 5:53 AM, Anonymous Anonymous said...

"There's nothing revolutionary..." Well :) I would think this is a good thing. Doing software research / experimenting in a resource limited one man project doesn't make much sense.

At 2:55 PM, Blogger Lachlan said...

You're right about it not making sense to be distracted by research/experimentation coding. The trouble is when you're a one man outfit you don't have anyone there to pull you back when you start to embark on one of those very interesting but not very productive excursions.


Post a Comment

<< Home