Dirty secrets of computer engineering
Imagine taking your car into the shop, they call back saying you need to apply a manufacturers fix to the fuel injection system, it may not fail now but soon. Instead you say, "No way! I put one of those fixes on before and it took a week to get the car working again!"
OK, my example isn't perfect but in the software world we are trending towards the wrong end of trouble-free updates. Don't get me wrong, software updates in principal are great, I like useful new features, fixes to annoying problems. The problem is that each user now has more customizations, more add-ons and the applications are more complex and modular than before. The tested patch may never go through the number of permutations required out in the field
There is a whole industry of "Change management" like ITIL, to essential mitigate the risk of a change causing a problem. However I found very little about identifying the root cause and technology to solve it. If you have a configuration file, which by its very definition implies it will be changed, how do you manage updates to that changed file? What if your reseller also changed it? How do you diff an XML file? Does a registry or configuration database help or hinder updates?
My colleagues Nimish and Vinay collected some of the current approaches and a strategy for configuration updates. There is also a new open source web-based diff tool, JSBlend. If you have used graphical diff tools before the web based approach should look familiar. The industry still has a long way to go to clean up the current state, I just hope we are heading in the right direction.