Friday, March 09, 2007

Software evolution and the DST mess

[Update: I'm wrong about the Java update. Sun went with a utility that updates the JREs, rather than a JRE replacement. In retrospect that makes far more sense, they had to make an exception this time and update the individual class separately. I think the 'tightly coupled' story still sort of works, it explains why Sun had to do things differently this time.]

Recently I bloviated about loosely coupled life and the evolution of software. It occurs to me that I might as well say something about the Daylight Savings Time mess that might reinforce that message. Or not!

The DST transition, from my perspective, is worrisome. I personally think Congress committed legislative malpractice when they mandated this change with a relatively short notice. They should have given us 10 years. I suspect I'm not the only person who feels this way, but we geeks are reluctant to say much since humanity mostly survived the Y2K transition [1].

Why is it worrisome? Well, there are a lot of reasons, and I think most corporate IT departments have already run into them. One of the more interesting examples, however, is Sun's Java runtime environment (JRE). (BTW, the same thing would be true of Microsoft's .NET, but it's less widely used, there are fewer instances in widespread use, and Microsoft learned from some of Sun's mistakes.)

The Sun JRE was an attempt to decouple the software environment from the underlying hardware and operating system. That's a seemingly admirable goal, but the implementation had a perverse consequence of different sorts of very tight coupling. Sun has updated the JRE as one large, somewhat integrated, chunk of code. It's a large and powerful collection of software services, and it all gets distributed together. In theory Sun could have updated one class at a time, but I'm guessing they found the JRE would be even more unreliable if the classes weren't synchronized. (Another example of the disappointments of classic object oriented software.). This means that all the services in the Sun JRE are tightly coupled.

The next part of problem was that, by my recollection, the Sun JRE was a huge and expensive disappointment in its heyday. Each tiny release seemed to break something different. Software that ran well on one release broke on the next one. Inevitably software distribution became dependent on a fairly specific version of the JRE [2]; the software was tightly coupled to the JRE version.

So now we have the situation of tight coupling between the classes in a specific instance of a JRE and tight coupling between a specific instance of a software product and a specific instance of the JRE. Bad enough, but along comes a significant mandated update [3] like the Daylight Savings Time update. Sun is not going to update very version of their JRE, only the most recent versions. So to get the DST update, software may have to jump several JREs to the current version. Ahh, but remember that "tight coupling" between the software and specific instance of the JRE? That's where things break. The software has to be fully tested with the new version of the JRE and it may need to be patched. Then the patched software has to be distributed ...

Well, maybe we'll all do just fine after all. Sun's JREs seem to be much better than they once were, so maybe all the software will make the transition better than they would have three years ago. We'll see!

[1] I personally think we mostly got through Y2K in good shape because thousands of people worked liked demons to fix things. In other words, on the spectrum from over-reaction to under-reaction, I think we were just a bit to the "over" side of "just right". That's pretty damn good for an ape, and it's a great example of how we do better than it seems we ought to do. Unfortunately we're still apes. Prevention is never rewarded or admired as much as recovery, so the popular perception is that the Y2K scare was grossly exaggerated. I suspect this has led a lot of people to understate the DST risks, but I know folks are still working hard to avoid problems. So we'll probably get through, though maybe a bit on the "under" side of "just right". It does help that Y2K eliminated a lot of software that would have been hard to patch for DST.

[2] Lots of bad things happen when you have multiple JREs on a single machine, but that's another story.

[3] Getting the rules around DST right is non-trivial.

No comments: