The evolution of loosely coupled systems

As always Joel Spolsky makes very good points in Joel on Software - How Microsoft Lost the API War but I think he missed a couple of critical issues in the "war" between the two forces within Microsoft (The Raymond Chen Camp (Win32) and the MSDN Magazine Camp (DLL Hell).

While I admire and respect the efforts that the WIN32 camp go to making everything backwards compatible, we as users of current systems are cursed with an overly complex system that is hard to evolve as its roots go back 20+ years. On the other hand the MSDN Camp believes that the evolution can be through shared libraries and that applications should share code and evolve through DLL's. As DLL's were not implemented well for evolution (VMS and UNIX did a lot better job even before Windows), we are stuck with an incompatible mess. From these two approaches one can see the evolutionary branching of tightly and loosely coupled architectures. The tightly coupled WIN32 approach is made to work through shear hard work, as Joel notes in his article the enormous lengths the Win32 team go to for backwards compatibility, any other company would go bankrupt from this level of effort. On the otherhand because the MSDN Camp does not have strong versioning and hence cannot provide developers a stable platform we have a loosely coupled mess.

As Joel goes on to point out this battle is really over and most of us have moved on. Whether you use, Java, Python, .Net (including Mono) we are getting further from the operating system, when I move Java code from Windows to Linux it typically runs unchanged providing I have set the properties files correctly and a few other details, the same is true for most other high level languages. The next challenge is as we move beyond loose coupling through DLL's and Shared Libraries to services defined in the network we do not repeat DLL Hell and ensure that we can version and reuse services through shared infrastructure. As more shared services run in the network the platform they run on will be all but irrelevant to the users of the services. What will be relevant will be availability, functionality and responsiveness.

What will be relevant will be the client technology, currently the ability to deliver web interfaces using DHTML is state of the art, but it is not progressing, and is too complex. Other, better solutions are starting to appear that are leap-frogging the current browser technologies, they still use the browser as an HTTP pipe but that is all. They are in the desktop but require a minimum from the desktop and are easy to develop and deploy. Solutions like XUL, DreamFactory, Flex, Avalon are going to be where the next war for control is going to be fought. As these solutions are completely decoupled from the backend services there will be a completely new loosely coupled development approach but we should remember the lessons from DLL Hell and consider how to version and evolve service interfaces