Tag: Frustration

Oh my! So here’s my fun, work-related rant of the day.

So nearly three years ago I was tasked with solving the problem of how we could install the same application on a windows box multiple times in such a way that we could isolate customer data. In short, each customer gets its own installation of the application operating in its own sandbox on the machine.

Microsoft, in their infinite wisdom, have crafted a whole installation management service. It can manage component registration, set up services, set up web sites, toss out a few registry entries, and track all of it in a little black book somewhere. It can use the information in this little black book to manage patches, upgrades, and uninstalls. All these things are really nice to have. It just seems like a really nice, awesome thing to have amiright? And it would be, except for the implementation, which sucks the guy up the street’s turds.

Long story.

Anyway, by going down this road, Microsoft also precluded the ability to install the same damn code on the same damn machine multiple times. There are many ways around this, most of which entail writing your own installer wrapper. There is also the concept of the instance transform.

See, MSIs are basically bundled, self-contained databases. The idea behind an instance transform is to run a process against an MSI to insert unique values or installation-specific pieces. Presto! Now we can install multiple instances of the same software on the same machine.

Now most times this is done, there is a specific set of values one is looking to poke into the MSI. Not in our case. For one, it’s not a task that is easily automated at build time. Also, it is “messy” in ways that management does not like. God forbid I use something with a dot MST file extension instead of dot MSI. Someone somewhere decreed that the only thing we can use to install an application on a machine is an MSI because, well, just because. So I was tasked with writing a set of generic slots that could be filled with information at install time. And Microsoft doesn’t support this nearly as well.

To recap then. I was tasked with, and developed a solution for installing the same application multiple times on the same machine in such a way as each application was unique and ran in its own space. Further, this had to be flexible enough to support arbitrary information which is only known at deployment time. Ostensibly this was so that we could shave a few dollars off our bottom line by supporting multiple customers on a single machine.

Turns out—and it took three years for this to come to light—the folks that use my work aren’t using it to trace a customer’s installation across versions over time. They’re using this to install multiple releases of the same product on the same machine and expecting this to just work. That it has to some degree so far has kind of been a happy accident.

Another fun initiative that $EMPLOYER has pursued is to break MSI patch/upgrade behavior by forcing the complete uninstall of a previous install before running a new installation. Because we can, we force all of our deployments though a Microsoft operating system management suite which allows us to add hooks to do stuff around installations. Because I’ve been successful in lobbying, we’re getting rid of this in favor of leveraging Microsoft’s built-in patch/upgrade installation functionality.

This will break the hell out of whatever it is the folks who are improperly using my transform work. Which is what I spent today discovering. The level of awesome I am currently enjoying is inexpressible. For three years I’ve been laboring under one set of assumptions while the production deployment of my labor has been orthogonal to those assumptions. More to the point, for three years I’ve been working from an improperly defined requirements set.

Three years.

And now we’re so far down the rabbit hole it’s likely that we’ll not fix things but just try bandaging what we have to get us through until the end of time. Because, after all, that’s three years of inertia. In corporate development environments that is an eternity and a functionally infinite force that is impossible to appreciably alter.

Three years.

Even more fun? This application was developed by our out-sourcing partner on a different continent. So instead of leveraging in-house developed and tested tools that allow us to facade an application’s services across releases, they came up with this bastardized foo-fah-er-y.

All of this, the stupid utilization, the inaccurate requirements documentation, the non-communication that the current paradigm doesn’t work well for their needs, all serve as anecdata about the true cost of outsourcing. See, because the only reason this all is coming to light is that we decided after three years that outsourcing development isn’t cost effective after all. Now we’re trying to unpack this monstrosity that we paid for and, in my case at least, we are well and truly fucked.

Three years.

My brain is asploded.