Software decay

At my company CODEFUSION we are working with bigger and bigger customers. We are getting hit by terms that were little known to us until now. Last time we did get a contract to sign with a term (literal translation from Polish) software “illness”. The word illness was in quotation marks. The term was new for me, so I started to dig. It turned out that what was meant here was probably “software decay” (called also software rot, code rot, bit rot, software erosion or software entropy). It was something we all software developers are fighting with. Sometimes without knowing it has a name. Software does not change, bits don’t rot, programs are not getting ill. But the environment in which they are executed often changes. New hardware is being installed, dependent software changes (for example database engine is being updated). So the software slowly deteriorates. Faults are being discovered that were never seen before, performance drops, the overall stability decreases. We see it everywhere: websites are “old” after a year or two, windows applications written for windows without tiles look “funny” in Windows 8. From experience I know environments where some ancient technologies are still used to develop the software because every one it afraid to touch a running system. So: software rots.

It was quite funny how quickly I discovered a decayed piece of software that was written partly by myself. I work with Visual Studio. For various reasons I’m deep into addins development for Visual Studio. To my surprise one of my addins stopped working suddenly. I haven’t done anything with it since a year or so. What I did I’ve done is I installed a new version of Visual Studio and unknown number of updates for both the old and the new one. Maybe it was what rotted my addin. So I quickly spin up the debugger and found that this line of code

   1:  _toolWindow = _applicationObject.Windows.CreateToolWindow(

   2:     _addInInstance,

   3:     _progId,

   4:     _caption,

   5:     _guid,

   6:     ref docObj);

rises an exception. ProgId seems to be wrong. No matter it was all right a year ago. Now it is wrong. Google seemed to know nothing about it. So I fiddled around. _toolWindow is a custom window for my addin. It’s “Windows” type. Visual Studio API is not the cleanest part of the code I’ve seen. Not surprisingly there was a “Window2” type. With a method “CrateToolWindow2” that produces an object of “Window” (of course not “Window2”). But it was exactly what I need. So I’ve changed the implementation slight to:

   1:  Windows2 windows2 = (Windows2)_applicationObject.Windows;

   2:  _toolWindow = windows2.CreateToolWindow2(

   3:     _addInInstance,

   4:     Assembly.GetCallingAssembly().Location,

   5:     _class,

   6:     _caption,

   7:     _guid,

   8:     ref docObj);

   9:                      

And voila! It magically worked. I have no idea why the class name is better than ProgID. Maybe it is an SDK update, maybe something else. But what ta heck! I will let it work until it rots again.