Mimsy Were the Borogoves

Mimsy Were the Technocrats: As long as we keep talking about it, it’s technology.

42 Astoundingly Useful Scripts and Automations for the Macintosh

Work faster and more reliably. Add actions to the services menu and the menu bar, create drag-and-drop apps to make your Macintosh play music, roll dice, and talk. Create ASCII art from photos. There’s a script for that in 42 Astounding Scripts for the Macintosh.

The Real Y2K Bug

Jerry Stratton, March 8, 1999

Point one is a simple one. The Y2K problem is not something you can put off until December 31. It will start appearing as soon as we start using dates greater than 1999. In some cases it has already started, but the biggest ‘jump’ in y2k problems before January 1 is going to be when fiscal years which overlap 2000 start kicking in this summer. Later on, products will start shipping with payment dates after 2000. You need to start paying attention now.

Point two is a rant. The biggest problem with Y2K is one of perception. I’ve been hearing this Y2K problem referred to a lot as a “bug”, as in the “Y2K bug” or “millennium bug”. It is not a bug. A bug is a mistake in programming. The computers are doing exactly what they were programmed and expected to do! The Y2K problem occurred because of a mistake in planning and a mistake in design. Programmers or designers, on writing software or building computers, made the decision or were given the decision to write software that only worked in the nineteen hundreds. Treating this as a one-time bug only sets us up for bigger problems in the future. We need to treat this as a basic problem in the way we decide how to design computer hardware and software. By treating it as a bug, we upgrade. By treating it as a design problem, we look for better design. By treating it as a bug, we’re rewarding companies who do things badly, over companies that do things right.

The most blatant example of this are the “Y2K budget lines” which are earmarked solely for use to fix Y2K problems. They are used to upgrade hardware and software which is not Y2K compliant, leaving less money for upgrading hardware and software which is Y2K compliant. At our University and across both business and education, this means that if you programmed or built non-compliant software and hardware, we’re going to give you more money... but if you programmed or built software correctly, we have to stick with the older versions because we haven’t got enough money after upgrading the bad software. We’re rewarding programmers and computer manufacturers for bad design. I’ve had faculty with Macs on their desktops beg me to tell our IS department that their decade-old computers are not Y2K compliant. Unfortunately, it just isn’t so. Since Apple built their computers right the first time, they can’t have any of our Y2K budget. I can’t imagine this kind of logic anywhere except computers. If Ford were to build cars that stopped working at midnight on December 31, 1999, our ‘motor upgrades’ would not replace our fleet of Fords with more Fords. If bad design on Ford’s part meant that we had to create a special “Ford 2000” budget line, we’d use that money with companies that build their cars right the first time.

The biggest Y2K problem of all is that we are training software companies that doing things wrong is better than doing things right.

In response to Year 2000 Minority: I appear to be in the minority among those writing about Y2K: I don’t feel it to be a world-killer, but I also do not recommend ignoring it.

  1. Y2K Addendum ->