The Source for Java Technology Collaboration
User: Password:



Calvin Austin

Calvin Austin's Blog

Dirty secrets of computer engineering

Posted by calvinaustin on July 10, 2007 at 05:11 PM | Comments (2)

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.


Bookmark blog post: del.icio.us del.icio.us Digg Digg DZone DZone Furl Furl Reddit Reddit
Comments
Comments are listed in date ascending order (oldest first) | Post Comment

  • In the past I've thought about saving all of a system's configuration and metadata in a Mercurial repository. That way when new updates arrive from a vendor they could be automatically merged into the local repository without wiping out the local changes.

    Posted by: emorning on July 11, 2007 at 10:49 AM

  • Keeping your changes separate is definitely part of the solution. This will work until the vendor needs to change something in the configuration file that an auto-merge cannot handle. syntax aware merge tools would get us a little further

    Posted by: calvinaustin on July 11, 2007 at 11:59 AM



Only logged in users may post comments. Login Here.


Powered by
Movable Type 3.01D
 Feed java.net RSS Feeds