colour me surprised

I work at a large medical facility, and I used to have to package and distribute software updates for a major medical software vendor that we use. In this model, our management would purchase whichever code modules that they wanted to implement, which were built by separate dev teams at the vendor site.

The various dev teams would send their modules, which consisted of EXE/DLL, etc. files, and a central .ini file with the date/size/version/checksum information for each file. Of course they had their own custom setup program which would install the files using this central .ini file, since the vendor didn’t even follow normal file versioning/overwrite rules. Sometimes one dev group would update a DLL file without even incrementing the version number, preferring instead to just change the date/checksum value in the .ini. It was often IMPOSSIBLE to consolidate all the code into a package for distribution to our workstations. The disparate dev groups did not seem to realize/care that I can only put one copy of a particular file in a particular directory at a time!

They sold all sorts of independent modules that had to share the same .ini file, same directory structure, same setup program, but they didnt test their code for compatibility with the other stuff on the same sales receipt! They were building a complex program consisting of THOUSANDS of interacting COM EXE and DLL files, but they were all testing against differing versions of the same dependency files, and each group was including the ones they tested against, and expecting that someone OUTSIDE the company (me) would sort them out and get them to co-exist.

Sometimes these announcements make you wonder if MS does things that way. They really should put all their code information into a DATABASE. Then they could make sure that people test against the same files, and they could also check to see if there are conflicts with other stuff theyre selling. Man, I bet their .ini file is getting HUGE.