I recently wrote a local program to do more useful job of reporting the status of our ZFS pools. To simplify slightly, ZFS pools have a number of flavours of redundancy; none, mirroring, RAID-5, and RAID-6 (currently). However, we only use mirrored pools, so for our own uses the program I was writing didn't need to deal with any other sort of pool.

So of course I spent a not insignificant chunk of time making my program handle RAID-5 and RAID-6 pools. And not just handle them, handle them just right, which involved deciding the severity of various faults in them. Maybe someday we will have a use for this and it's certainly correct, but in the mean time it's functionally useless.

This is a perfect illustration of one of my abiding sins in programming (strictly speaking, in development). Left to my own devices, I can easily wind up spending an inordinate amount of time on picky issues that ultimately don't matter for what we need today's program to do. It's hard for me to do otherwise, because I can always see one thing that the program doesn't handle right, or one bit of output that could be improved, or what have you.

(For me this usually manifests as a nearly endless obsession about fine tuning the program's output format.)

Thus, once again, I need to learn to sort out what we need now from the perfect answer to the problem I've set, and to accept that I don't need to handle some cases because they're ones that we don't care very much about or have no use for; it's the core functionality that matters. And when that core works, I need to let go of my feelings that the peripheral things aren't right and need to be polished more. Especially for local tools, the urge for generalism and perfection is a time-wasting mistake (or at least a danger).

It's not an easy thing. Polished, complete code gives programmers a warm feeling of satisfaction (and for good reason in many cases), while there's little joy in code that you know is incomplete and limited. The temptation to spend ten minutes or half an hour or whatever to fix some of those little nagging issues is always there. More than that, I think that such polishing is addictive, partly because it gives you a series of rapid feedback and rewards. It's sort of like unit tests; you can handle a new case or make the output better and ding, you've gotten that feedback. The program is improving before your eyes, never mind that the improvement is unimportant.

(Note that the rules are different for tools that are intended to be general from the start; there it's not a mistake to handle all of the cases, it's part of the requirements. Whether sysadmins should write general tools even when they only need local ones is one of those interesting debates.)