Fixing Future Mistakes
There is a process in hardware and OS management that I like to call Configuration Jeopardy. It’s when you’re working on a particular task and you spend hours or days trying to solve a problem that you know should be easy to solve but neither Google nor in-built documentation are any help because you simply don’t know the right vocabulary. I’ll take a single line to add in an obscure file in a subdirectory /etc for $500, Alex.
Whenever I manage to solve a problem like this, I want to find a way to amortize the cost of finding the answer for the poor sot who has to do it again in the future.
Here’s an example – I had upgraded an OCR engine as part of my tasks for DotImage 8.0. All OCR engines that I’ve worked with can be a little quirky in terms of how to get them going and how to find their resources. I’ve put in infrastructure in our code to make this as easy as possible, including code that will use an Atalasoft registry entry, if present, to help find OCR resources. In the upgrade, I had unit tests that ran fine on my machine and ran fine in the continuous integration build, but were failing the nightly build. Eventually, I narrowed down the difference to the fact that my machine and the continuous integration build had no problems finding the resources, but the nightly couldn’t.
I put in debug checks and eventually found that the issue was that the build server was 64 bit but since the OCR engine is 32 bit, it was looking in the WoW 32 bit registry. That cost me 3 days of fiddling with debug scaffolding and waiting for nightly builds and unit tests – and would’ve cost more if I hadn’t been bouncing this problem off of one of our other engineers.
So how do you prevent this in the future? One is to have a clear process in version upgrading that includes this (note to self – we need this). Another is to put a sign post in the point of failure making it clear what to do. To address the second part, I added a registry subkey in the area I had looked at that was named something like “WhenYouAddASubKeyHereAlsoAddItToXX”, where XX was the location in the WoW node.
I like to think of it like the Boy Scout adage of always leaving a place in better shape than when you found it.