Reliable code -- is it even part of the plan?
Published: 02 Aug 2000 13:12 BST
Oh, I don't doubt that most Microsoft programmers prefer to write good code, that doesn't. Nor do I mean that they are too thick to be able to write good code - far from it, Microsoft has been able to hire the cream of the industry for some time.
But the list of things that don't work is long. For example, I'm busy testing the new PalmOS machine from Handspring. An application just in for testing on the Handspring is one that ought to work reliably. And it doesn't.
The reason is that the Handspring Visor talks to a PC through a Universal Serial Bus (USB) cable. The developers naturally want to work on a stable machine, so they develop on a Windows NT 4.0 (SP6) box. They can't test it with Windows NT's virtually non-existent USB handling, so they're trying to write under Windows 2000. Each time the application is compiled, it has different results - not because they've changed their code, but because the Windows 2000 API has changed.
Take Laplink 2000 -- an essential utility for anybody with more than one machine. Several features of Laplink 2000 are unstable on Windows 2000 - well, so what?
Talk to the developers, and it becomes apparent that they get a different "build" of Windows 2000 every day, and that there are patches, fixes, addenda, and basic changes to what they can and can't do. There are support DLLs that aren't in the release candidate that we've all got (RC 2) and as a result, there are software features that aren't available.
These aren't the only two developers I've spoken to in the last month or so; and these aren't the only developers who report the same problems. Basically, there are still design changes in Windows 2000, a month away from "release to manufacture."
How can this be?
Previous
Did you find this article useful?
19 out of 37 people found this useful
Digg
Slashdot
Del.ici.ous
Stumble
Reddit
