Who needs my software errata?
or, Updating Anonymous Subscribers
This week I've been bitten twice by the same problem, and had to live with the infamy of being the offending party in one of the situations.
Say you're providing a library (and associated headers)(or a generic service) to an interested party, without necessarily adding them to a subscription list. Such a list would be the most reliable mechanism, certainly, but one doesn't always have the luxury of (pick your choice) being able to collect this data, or having the time to update/consult it etc.
Versioning would also help, provided it is accompanied by broadcasting the current "safe" version, and provided that the interested parties poll for updates. In one of the cases I mentioned above, a dll I wrote and used by another group took on a new dependency. The dll was consumed by their own harness/component and, as you may have guessed, the setup of their component was not updated to copy the new modules. One or even two days of runs were lost (with detection, investigation and what not). Now they are on my list, but I'm not sure whom else can I add to the list. So, what's the solution?
The second of the two was a more classical example of broken backward compatibility. A widely used logging component (part of a larger system, let's call it UTT) revised the behavior of a method it exports. But instead of a more straightforward crash/fail when the old-style params are passed (which would instantly attract attention), it quietly went about working, in an invalid state, crashing only upon exit. The investigating parties had no idea such a change occured, and were exchanging pleasantries ("I think it's in your component", "Actually, I think it's in yours" "Mine hasn't changed" "Neither has mine"). Presumably, this is where versioning might have helped. But the detection of a version newer than expected would probably prevent situations like these in less than half of cases. (And the consumers would incur the cost of investigating whether the new version of the service provider should translate into updated client code. (Well, the second example was a simple case of dumbassness, but there's got to be a protection against that also.)
I'd love to hear your thoughts, words of advice (or condescendent snickers, as long as you have a simple solution to this).
Tevio Destre
3 comments:
For your first case, you can probably look into distributing a wixlib/msm/other setup module that your "clients" can easily slurp into their setup. Kind of hard to offer better advice without knowing more about the module and its dependencies.
For your second case, there are a number of different potential problems and solutions depending on the nature of the components, your build process, who builds them, who distributes them, etc. Mixing and matching versions of components in an automation environment is just asking for headaches. If at all possible, all test components should be built with and version paired with the version of the product you are testing. If not possible (and I can pretty much guarantee you this is the case), as many of them should be paired as possible.
Getting the versioning problem figured out pays other dividends in the long run; I could write pages on this stuff, but your probably get the point. :)
That being said, the problem you encountered is probably the worst situation you can run into, given that it is very difficult to gain any traction on the problem -- the responsible party doesn't think they're responsible, and the impacted party doesn't know enough to say for certain. I think the way these sorts of situations develop is due to the adversarial nature of bug passing; if you change tactics and try to get both parties to work together instead of assigning ownership to one party, things tend to go much smoother in my experience.
For your first case, you can probably look into distributing a wixlib/msm/other setup module that your "clients" can easily slurp into their setup. Kind of hard to offer better advice without knowing more about the module and its dependencies.
Thanks for stopping by. Indeed, hard to find a solution without details, but I'd like to use this blog for more than simple technical issues ;-).
Having said that, there are formal distributions of the package (wix), but the problem occurs with those that create their own (informal) jobs and fall off the map of "active clients".
That being said, the problem you encountered is probably the worst situation you can run into, given that it is very difficult to gain any traction on the problem -- the responsible party doesn't think they're responsible, and the impacted party doesn't know enough to say for certain. I think the way these sorts of situations develop is due to the adversarial nature of bug passing;
Absolutely, and no matter how strong of a proof of rightful ownership I offered, it still came back to me. It's difficult to work on a issue across groups - rarely the two parties agree on the priority of it. I spent some time investigating this and (among other things) the issue was apparently caused by the provider publishing two versions of the same header (and they were different). Our code included the old header, linked to the new lib -> stack corruption.
Absolutely, and no matter how strong of a proof of rightful ownership I offered, it still came back to me. It's difficult to work on a issue across groups - rarely the two parties agree on the priority of it.
How quaint, replying to my own comment. On the same W^HUTT issue, apps continue to crash when logging and that drove me up the walls. Tonight I've had the pleasure of working with a real person, trying to debug it. (Big kudos to the Windows Communicator, the tool absolutely rocks. We were talking and debugging at the same time, much better than an over-the-phone similar concerted effort.) Suddenly, "they" don't seem so much as the enemy, and "they" probably don't consider me as such a pest either (hopefully). Email is a terribly impersonal medium, no matter what. Here we were, both nearing our 12th hour for the 4th time this week, trying to grasp this new, weird stack corruption while learning a bit more about each other's habits, tools and warts of teammates. (No, we weren't gossiping.)
You may think I'm going soft, but most of the time, our job is that of a lone wolf, with little social interaction to speak of. Yeah, I talk to team-mates, but I don't hold all of them in high regard and it's a rare occasion when we work on towards a joint goal. (And me spending lots of time fixing their bugs does not help either.) So once in a while you develop an unlikely acquaintance on the other side of the campus, and it feels good to find someone fighting on the same barricade. I just knew we can't be all alone in this campus of 35,000 (and growing)(hi, Mini!).
Post a Comment