More archaobugology
They do keep coming out of the woodwork. I've just found, and fixed, another 5 or 6 years old bug lurking in a key bit of software ('=' signs appearing in the value part of post or get data were being dropped). I'm starting to realise just why so much of our software is a fragile as it is, and getting increasingly frightened by our reliance on computers for critical things. Mind you, I've been reading comp.risks for years, so shouldn't be that surprised.
On the details of the work, the new gazetteer is coming along apace. I plan to go live in the second half of February. It won't be finished, and will still have some bugs in but (putting aside the fact that - as shown above - everything still has bugs in it) it will be less of an abomination, and cause less harm than Google's recent changes to their interface to Usenet. And, again unlike Google, I won't be breaking anything that was long established before they came along.
1 Comments:
hi nick,
Have you thought of implementing a Test Driven Design process to help iron out bugs and give you confidence in the code, so it doesn't seem to 'fragile'. I've noted a couple of links that outline the general premise.
Once you get used to the way of working and starting with a fail it becomes almost second nature to develop this way. The one caveat I would add is that you need discipline sometimes to carry this out when you're under (time) pressure to get something done, but I think it pays dividends in the long run.
It's also handy for when you revisit the code and try to work out what exactly you were thinking at that time. The tests help to document the expected behaviour of the code being tested.
Anyway, these may be of some use:
TDD intro
Wikipedia
cheers,
paul
Post a Comment
<< Home