I just made about two dozen changes to the DB schema -- little stuff, but pervasive. (I'm cleaning up the code to match Java coding standards, which are subtly different from the C# standards I'm used to.) In many cases, that would simply be too damned *scary* to do: since many of the changes are inside SQL strings, I don't have strong typing to save me from my mistakes. This fear of completely breaking the system is the source of much of the cruft in typical programs: routine and appropriate cleanups just aren't worth the danger that they impose on the system, so they never happen.
But this time I've built the system appropriately, with a reasonably detailed test harness coming in from the very beginning. It doesn't cover absolutely everything, but the coverage is good enough for me to have considerable faith that the system is still working. So I'm able to make a change that touches a couple dozen files, in various risky ways, in just a couple of hours, and check it in with confidence that I haven't caused the end of the world.
A little thing, but a good reminder of why it's worth putting in the time for this kind of overhead stuff from the start. It may be a little frustrating to slow down and build the system right, but it pays off big down the road...
But this time I've built the system appropriately, with a reasonably detailed test harness coming in from the very beginning. It doesn't cover absolutely everything, but the coverage is good enough for me to have considerable faith that the system is still working. So I'm able to make a change that touches a couple dozen files, in various risky ways, in just a couple of hours, and check it in with confidence that I haven't caused the end of the world.
A little thing, but a good reminder of why it's worth putting in the time for this kind of overhead stuff from the start. It may be a little frustrating to slow down and build the system right, but it pays off big down the road...
Testing
Date: 2008-04-15 12:15 am (UTC)My work project, not so much; I dove into Rails without stopping to read how to write unit tests first. However, when I needed to do a substantial library in JavaScript (an expert system engine), I wrote unit tests for that, and they were a big help.
I'd still rather work in a strongly-typed language like ML, where the type system can encode semantics that you would otherwise have to test for. My manager at Endeca used to work on compilers in ML; he said that, in his experience, once you got something to compile, it was always bug-free. I'm fairly sure he's exaggerating...but not by much.
But finding people to work in ML is a hard problem. Especially since the rest of the company is in Philadelphia.