One of my favorite quotes about the art of software development is

You cannot eliminate complexity, all you can do is move it around

This is very true when it comes to designing systems. You should always look with skepticism when someone tells you that some development tool or technology eliminates complexity. Usually this means the complexity has been hidden but lurks just below the surface waiting to ensnare unwary programmers. However on certain rare occassions, the complex part of the problem is actually solved by the tool or technology effectively eliminating from the worries of the application developer. This is very rare.

A good example of a technology which eliminated complexity for application developers by moving it into the purvey of runtime frameworks is garbage collection. The complexity of memory management was eliminated as a concern of application developers and moved into the domain of application framework developers. This was a win for the industry since the complexity could be relegated to realm of language runtime gurus.

There are lots of examples of technologies that claim to "eliminate complexity" but actually just move it around in a way that makes the complexity less obvious. This is often because, the person claiming to be eliminating the complexity fails to acknowledge where the complexity lies in the first place. For example, when the .NET Framework was first shipped by Microsoft there were lots of claims that DLL Hell would now be a thing of the past. You can still find blog posts and articles like Simplifying Deployment and Solving DLL Hell with the .NET Framework from that era claiming that "DLL Hell" is solved. The problem with that thinking was that versioning and keeping libraries backwards compatible is a fundamentally hard problem that often has no good solution. At the end of the day, you only have two real choices when it comes to preserving backwards compatibility; never change the existing functionality of a library or always ensure that applications always run against the original library they were compiled against so that if the new one changes behavior, they are unaffected. Both choices are untenable which means there will always be complexity when it comes to how one handles versioning and system libraries.

It’s been about six years since the first versions of the .NET Framework were shipped and such hyperbole has died down. Today you can find posts like What A Difference A Revision Makes - IConfigMapPath Is Inaccessible Due To Its Protection Level and Microsoft .NET Patch May Make PCs Go "Haywire" which indicate that DLL Hell is still alive and well when it comes to programming against the .NET Framework.

This brings me to my point. Recently Shawn Steele of Microsoft wrote a blog post entitled Security patch MS07-040 for .Net 2.0 breaks some culture names for .Net 2.0 on Windows XP/2003/2000 where he writes

The .Net patch of July 10th, ms07-049, changes culture names to use the new names on Windows XP/2003/2000 as well as Vista...Unfortunately this change can break applications that expect the old names.  If that happens, the workaround of creating custom cultures might work for your application.
…
Potential problems experienced by applications could be:

• client/server communication because one used the old names and one used the new names.  A workaround is to create custom cultures with the old names and choose a parent fallback for them.
• Visual Studio projects probably need migrated to use the new names for the resources, otherwise there could be confusion compiling and loading resources.
• If this is your system locale there could be problems loading resources using the old name, depending on the behavior.  In this case creating custom cultures for the old names and replacements for the new names with the old names as the parent culture may solve the problem.

This problem affects the following cultures supported by RSS Bandit; zh-CHT->Chinese (Traditional), zh-CHS->Chinese (Simplified), sr-SP-Cyrl->Serbian (Cyril), and sr-SP-Latn (Latin).

The blog post is unclear but it sounds like RSS Bandit may for our Chinese and Serbian users who have updated their versions of the .NET Framework. However I’m not 100% sure this is the case. If you are an RSS Bandit user whose environment is set to Chinese or Serbian and have applied the recent .NET Framework security patch, please respond to this comment with information about any problems you are facing or let me know if there are no problems.

Thanks for your continued support.

Now playing: T.I. - Big Things Poppin (Do It)