![]() |
|
| Daemon News Ezine | BSD News | BSD Mall | BSD Support Forum | BSD Advocacy | BSD Updates |
Wes Peters <wes@softweyr.com>Copyright 2004 Wes Peters.Leading the MobOne of the columns I read regularly is the BackSpin column at the back end of Network World magazine each week. I enjoy Mark Gibbs' sense of humor, and this column helps me keep in touch with what's going on in the minds of my customers. I don't always agree with what Gibbs has to say, but I rarely actively disagree with his viewpoint. This summer, however, Gibbs came up with a doozy. It's been quite a summer for the IT types here in the USA, and one of the current hot spots is a conflagration between hospital IT departments, medical device vendors, and the US government Food and Drug Administration.
Gibbs has gotten a bee under his bonnet over this issue, covering it a number of times. It's a pressing issue, sure, who wants a virus to kill a hospital patient? The problem stems from vendors of medical equipment burying insecure (mostly Microsoft) operating systems into their products and then allowing them to be attached to the general, unprotected LAN in the hospital. The FDA, which is responsible for certifying that medical equipment is safe and accurate in the USA, doesn't allow the equipment to be operated if the installed software has been modified. The vendors can't keep up with the flow of patches in the systems they've chosen to base their products on. In the meantime, the hospital IT staff are caught between the FDA and the need to patch the machines in order to keep them functional, let alone secure. Gibbs has done a reasonably good job of explaining this dilemma, and how the solutions are more political than technical, but he seems to have skipped over one succint point. In an earlier article where he laments the recent spate of security problems in Windows, Internet Explorer, and a host of other Microsoft Products, Gibbs writes:
"We all bought into its "innovative" products because we had business problems that had to be solved now, and Microsoft had the solutions. Unfortunately, neither Microsoft nor the best and brightest in the IT industry ever foresaw where we would wind up." Whoa there, pony. To repeat a famous mis-quote from an America TV figure, "Who's this we, white man?" Many of us, pundits, experts, hackers, and just the ordinary working drones down here in the trenches of software development had been saying Windows wasn't good enough since way back when everybody knew it wasn't good enough. Good enough for what? You name it. If it can't run a word processor without crashing, it's certainly not good enough to run medical test equipment. I guess we just didn't qualify as part of Gibbs' "best and brightest." In point of fact, we were often dismissed as cranks, naysayers, and "UNIX bigots." (And they said that as if it were something bad!) All along, "mainstream" computer rags kept slopping at the advertising trough and telling you Windows really was "enterprise ready" and "mission critical." Whether they knew it wasn't or were just presenting the party line for their advertisers was immaterial, their job is to sell magazines, not to create medical instruments. The people who do make medical instruments, however, should and must be held to a higher standard. The other part where Gibbs stepped off the deep end is in this telling statement: "What really chaps my butt is the idea that device vendors are somehow responsible for the environment that their devices are deployed in!" Obviously Gibbs has never worked in a product development organization of any sort. It doesn't matter if you make baby toys or nuclear missiles, you are always responsible for understanding the environment your products are used in and for making products suitable for the environment. This applies to software as well as any other product. This was all brought back into sharp focus by watching the FreeBSD and NetBSD teams approaching very important releases. Both have shown their focus on producing a quality product in their attention to detail and their willingness to focus on the quality of the release rather than an arbitrary date picked long ago. This is exactly as it should be, and both teams seem to have a clear understanding that these releases are crucially important to the survival of their operating system progeny, and perhaps to the teams themselves. One of the struggles in bringing these systems to "release" standards is in reproducing the environments in which users -- the customers, in other words -- actually use them. Without the dedicated testing labs, and the multi-million dollar budgets that drive them, the process often devolves into debugging through a phone call, or worse an IRC conversation or email, or even emailing crash dumps and debugging traces. This is real hero work, especially when you are not being paid to do it, but just out of professionalism, pride in your work, or a talent and willingness to help others. References |