Nothings Changed

 

I swear that this will be on my gravestone when i die,

‘Here lies the Proud Salopian.

Nothing’s Changed,

Late as always’

Nothing’s changed, the mantra of every software developer that has ever coded anything which made it outside their bedroom.

It was a conversation with one of my bosses that started this blog off. I was having issues with a web project that had suddenly stopped working and was talking about my epitaph when he remarked that it was a phrase that wound him up as that whenever non technical people used this phrase it would normally turn out that something had changed! I know what he means, Calls to the help-desk are a constant reminder that things change all the time its just that most of the time the user has discounted them as they have no knowledge of how a thing works or they cannot see a connection between two pieces of software. The truth is inside the average operating system environment, things change all the time. Files are being written constantly, logs made, optimisations applied and decisions are made on your behalf. Generally, the user has accepted these changes and when they say that nothing has changed they just don’t remember the day by day events that have shaped the eco-system of their digital working environment.

Sometimes, just sometimes, things do change for which there is no explanation and there certainly was no sign up. Take my most recent example. I was beavering away fixing some bugs on an MVC application that utilises Structure Map for our dependency injection (if you’re not already using this, seriously…. why not?!). For reasons of hunger I stopped and had my lunch, well nearly…. in the main I actually struggled for forty minutes to book two rooms using the Travelodge site for London in June (Foo Fighters, enough said). I then decided to spread my workload a little and prepare a video for a bug report that we were lodging before finally deciding to come back to the MVC app.

That was when my troubles started… Prior to all Travelodge related swearing the application was building without issue, but, no longer. Odd, The issue was with the dependency injection not finding the classes to inject into my controller. I’ve had similar issues in the past which were down to initialisation code not being run due to a change in namespaces and the like. So I checked and double checked but to no avail. So I cleaned my project, and rebuilt. This time I got a compilation error talking about not being able to find BusinessObjects.Enterprise.Sdk.ZipLib.netmodule; Stranger and stranger, I didn’t need this file before, we were using Crystal Reports within the project and I have had to use these netmodule files before but not in this case. So investigations into this took a circuitous route right the way back to the first ‘Nothing’s Changed’ event that had occurred (Thank Darwin for BitBucket and more precisely SourceTree is all I can say) An investigation in the code changes made to my project led me to the fact that somehow my 64 bit project had become ‘Any CPU’ in the time between receiving a run time error and doing a clean. OK, really not sure how this happened but I’ll give VS the benefit of the doubt today. So I forgave quickly and built the project expecting my site to fire up but…. BANG. Again I was back to the dependency injection issues. Most vexing, so I stepped through the code and saw that all my controllers and Business Interfaces were being correctly registered with the Dependency Resolver. And then whenever a call was made to instantiate the HomeController over it would go. I must admit, the first three or four times I saw this I just saw the overarching headline that it could not invoke the controller, I had after all recently implemented the IDisposable Pattern on this controller and so maybe this was the issue (Although… I was sure it HAD worked at the time!). Reversing the IDisposable code and trying again made no difference at all.

After a while I looked deeper into the instantiation message and realised the issue was with one of the classes being instantiated to pass into the controller. My Controller was expecting a ICbConfiguration instance to be injected at run time which seemed to be the source of my problem so I ‘opened’ the implementing concrete CbConfiguration class in Visual Studio, Except, this didn’t happen! The file was instantly shelled out to Notepad++ and I was presented with something that looked nothing like my class. It was just lots of [null] characters which would in no way have ever satisfied the interface requirements of ICBConfiguration. I thus discarded all local changes and when I got my class back I felt more confident. All built OK and upon running…..

Bingo! My site was back and fully operational. My ‘Nothing Changed’ stance was now firmly apportioning blame to the software. Maybe, just maybe I could have changed the build to a 64 bit build but the CbConfiguration file had not been seen, let alone touched for months (at least from a point of view of refactoring).

I know that somewhere deep within the bowels of my machine is a grumbling piece of code that now sits at ease with its surroundings, in harmony with its eco-system and doing the job it is supposed to. I like to think of it as a little hairy creature that is a bit of a boffin on the quiet, slaving away with its chemistry sets creating software ointments and potions that just work and keep my files healthy. I like the idea of him, but I know that one day, I will find him slumped unconscious over a desk with blackened singeing fur; He’ll be surprised by my sudden appearance and will swear that he knows nothing about file xyz that is sizzling away in the corner, scarred at the edges. I’ll ask him what happened and I know that he’ll just say

Nothing’s changed.”