Talked to the manager about the design change. I'm not too happy with the weak reasons he gave for that. I'd say he was trying to weasel his way into a justification but that would be an insult to all the good weasels out there. Ultimately though that may just play into my hands. The code has been bent back and forth in so many ways that ultimately, I will be the only one who even has a clue how it works. Rather lousy way to get job security but I'll take it.
This, folks, is the real world of software development. Let not the glossy magazines with the design methodologies and patterns and all those fancy new programming models fool you. (Those are great for reading in the necessary room though. :) ) It's just downright dirty and complicated, and full of bad decisions that are not all the fault of those who write the software. It just gets messier and messier until one day, the whole product has to be re-written from scratch. But what the hey... the money's good. :)
Went out in the rain at lunchtime and visited two virtual caches in Westchester. The coordinates for one of them were off by a half mile or so (I didn't check the GPS) but I found it using the clue and my eyes. (Yes, those are very important cache-finding tools.) I guess it also helped that I made a wrong turn and ended up right at the cache site.
The odd thing was there was a travel bug there. What? At a virtual cache? Yes, it was lying right there in the flower bed next to the memorial. No container. Unfortunately, since it had been raining for quite a while, the travel bug was also rather soggy and a bit muddy. I don't think it makes sense to leave a travel bug at a virtual cache. For one thing, it will be exposed to the elements. For another, what about the next cacher who comes along? He could be searching the whole place over for a travel bug that was already claimed. If there's no container, how could he tell if the travel bug has been taken or if it was just really tiny and well-hidden?