To each his own SCM

Everybody offers a scheme. Retail shops, malls, online marketplaces ... nobody misses an opportunity to bundle goodies (3 for the price of 2, and a 1 year warranty instead of 6 months) and make a killing. By-and-large, I opt-in when such a scheme fits my plans.

But why say it here on this blog? The reason is, I am primarily a programmer. Retail, and 2-for-the-price-of-1 sale of end-user goods is one thing; the same applied to software applications of reasonable complexity can be a recipe for disaster. A software program is rarely ever totally standalone; there may be the odd application which may run off a CD/USB drive but such are few and far inbetween. A typical application relies upon API provided by the operating system, support libraries locally and online, thrown together in the right configuration for it to work. It only takes one small casual change for the whole house of cards to come crashing down. A support DLL updated online, a different JAR deployed, the PATH variable modified to change which directory appears last to an application ... these are a few changes that invite trouble.

Glassfish + jdk, or Eclipse + Borland compiler, XYZ assembly + Microsoft Office are a couple of examples in point. Applications that bundle software together use internal variables to reference the bundled library. When some such bundled library is also used by other applications the user may decide to reference the library across applications. This is fine ... until some such application executes an update for the bundled library which the original application can not use. Depending upon the boot sequence for the original application; not only will the original application now fail to start, but the user may probably see an error-free log too. Disaster!

To prevent such an error happening both application users, and developers must be educated. First, the latter must learn not to bundle a referenced library; instead use the installer to tell the user to install the library ... or fail installation. The latter must learn to use their internal variables to reference system variables. Too the former must learn to maintain a restore-point, or it's equivalent when an application is installed/uninstalled. Whilst this may not serve as a catch-all, it will probably serve to reduce user/support developer frustration ... a little and those who tinker continue to have fun!!