I held off submitting this in the hope that someone who knew the complete story would post it; that hasn't happened, so here's what I know. There was a very close, and racially-charged, mayoral election in Yonkers, NY; the challenger was rather unexpectedly reported the victor by 4,000 votes on election night. When the official tally was started, though, the incumbent had picked up 1,500 votes in just 5 of the 12 precincts. The count was suspended for the weekend, with the voting machines impounded; when it was finished, the original result — and numbers — were upheld. What happened? It's an old story here, I'm sure. Before the election, the tally program was run with test input data. They forgot to take out the test data when tabulating the real returns. From the story I heard, it wasn't clear if the error was in the official tally or in the early returns; given the numerical result, I tend to suspect the former. --Steve Bellovin
Roddy Stinson is a columnist for the San Antonio, Texas "Express-News". Here's one Question & Answer from his column of Nov. 14, 1989 under the headline 'RAINSTORMS DIDN'T STOP THE ARMY WHEN I WAS IN IT': The complaint desk is open -- PLAINT: I am a retired Army sergeant. My wife just got out of intensive care at Brooke Army Medical Center. I tried to call BAMC to make a medical appointment for her, and this is the message I got: 'The patient appointment system cannot operate at this time. Due to inclement weather, the computers had to be taken down. Please continue calling periodically. Thank you. This is a recording.' That's pitiful. That's ridiculous. What happened to typewriters and phones? If a rainstorm can shut down the country, we're in big trouble. I'll tell you one thing — rainstorms didn't stop the Army when I was in it. They told me to keep marching, and I did. [Stinson:] A spokesman for BAMC explained: "This (computer shutdown) happens every time there is a possibility of thunderstorms because the central appointments system is linked to a mainframe a mile and a half away, and if lightning hits the lines, everything on there could be erased." When I expressed skepticism, he added: "Believe me, it has happened. Lightning takes out our phone system and electricity on a regular basis." Progress marches on.
Upon doing a routine, periodic inquiry of the local credit bureau to make sure they have things reasonably straight on my credit report, I made a rather disturbing discovery. The report issued to me, and presumably to whatever business (or person representing themselves as a business) contains not only the expected credit information, but THE NAMES, CREDIT LIMIT, ISSUERS, AND CARD NUMBERS OF ALL MY CREDIT CARDS AS WELL! It might pay others on RISKS to find out if this sort of thing is SOP, or merely the result of the incompetence of our local bureau.
My bank, First Interstate, has recently implemented a handy new service. Using any touch-tone phone, bank customers may get information about the status of their account at any time. Normally, to get an account balance, the customer must enter the amount of his latest deposit. This provides, I feel, at least some measure of security. The problem is that the system also allows merchants to check a check. That is, will a check, for a certain amount, from a certain account, clear at this time? There is no security for this procedure. The merchant simply dials, enters the single digit code "6 - Validate a check" from the vocal menu, enters the account number, and finally the amount. The computer will then return a boolean clear/no-clear. Computer Science students will recognize this for what it actually is: a medium for a binary search. (At this point I refer the interested reader to _Sorting and Searching_ by Knuth.) The potential for abuse is obvious: Given the account number, it becomes trivial to find the account balance. My only shock is that the designers of the system were so casual about the RISKS involved. John H. Osborn, University of Texas at Austin Comp. Sci. Dept.
[Brian sent me two versions of the MTS saga, part of one of which ran in RISKS-9.45 — but without the explanation indicating that the MTS message was not from Brian but rather from someone else. The surrounding text is given below, in case anyone thought that the "We apologise ..." message was originally Brian's. I apology to Brian in case anyone was misled. PGN] The university computing service here runs MTS (the Michigan Terminal System) on an Amdahl mainframe, which crashed mysteriously today, as did various other MTS sites in North America, some time later. The explanation is given in the following message which I have just received from one of the systems programmers here. > We apologise for the unexpected system shutdown ... [see RISKS.9-45 for text.] I hadn't realised that there was this disadvantage to living on this side of the Atlantic! Ah, well, it makes up for various advantages :-) Brian Randell
}... A computer professional, on the other hand, doesn't trust them }*because* he or she *does* understand them (and their limitations). This also }lead me to realize that ours is one of the few fields where we wouldn't }necessarily trust our "product" with our lives. That is, doctors generally }will trust other doctors to operate on them, auto designers probably drive cars }(8-)), etc. Yet, a programmer probably wouldn't trust a computer-controlled }plane or car very much (for good reason, in my opinion). I'm not sure exactly }what this says, except that it is still a very immature field. One of my oldest friends is an anesthesiologist. She put off having a hysterectomy until she was nearly incapacitated because she knew all the things that could go wrong during the operation. I'm a licensed aircraft mechanic (and pilot). If you knew what I know about mechanics you'd think twice about getting into an air liner (though I do fly when necessary). I stay away from helicopters, except for emergency situations, because I know just how complex and fragile they are. I wonder how many other experts in life-critical systems could scare us with their specialized knowledge. The Polymath (aka: Jerry Hollombe, firstname.lastname@example.org), Citicorp(+)TTI 3100 Ocean Park Blvd., Santa Monica, CA 90405
In RISKS 9.45 David Benson quotes from a Science article by M. Mitchell Waldrop: ... But flexibility is precisely what the spell-it-out-up- front procurement culture lacks, says the report. In addition, the bureaucracy balks at the big up-front investment in problem definition that must be made when the evolutionary approach is used. These two sentences seem inconsistent to me. What's the difference between "spell-it-out-up-front" detailed specifications, and a "big up-front investment in problem definition?" There's some fuzzy thinking going on here. I agree that it is impossible to precisely specify a large software system when the hardware environment and functional requirements aren't frozen. In those situations it may be necessary to prototype the system in order to understand the problem. But I don't believe the software development community has reached consensus about tossing out the waterfall method. My feeling is that it is our inability or unwillingness to document requirements and specifications rigorously that is the source of most fiascos. Maybe the government requires the wrong kinds of details in its specifications, and doesn't adequately review them for sanity. How will switching from "specifications" to "problem definitions," and then hacking together a prototype which is then "evolved" solve any problems? This is the old method of software development that modern software engineering methods are trying to get us out of. Only if you throw away the prototype might there be hope you can then specify the system correctly. --Franklin Davis Thinking Machines Corporation
In Risks 9.45 David Benson discusses bugs in government software and discusses some of the causes/reasons behind them. I'd like, some day, to actually see two notes in the forum at the same time in a scenario like: David discusses problems with detailed up-front procurement specs and someone else discussing the problems with less-than-complete procurement specs causing problems. It seems to be a no-win situation. Those up-front specs didn't come out of nowhere. They were Congress', watchdogs', politician's etc. attempts to solve a problem. In typical Congressional ways, they use atomic weapons to kill flies(!). Each line in those regulations was probably the result of some (comparatively) trivial screw up. It has since cost us multiple orders of magnitud more to "fix" the problem than to let it alone. David's suggestion to abandon the waterfall approach to software design is good, but it carries the rather large risk that if it doesn't happen to work ONE TIME, you might get a "Golden Fleece" award and have your career dead-ended. As an interesting aside, I found issue 9.45 to have more meat in it than many in a long time. David's discussion, and the discussion of technology vs. policy is what this forum needs more of. Maybe the recent chastisers have had a good effect. Thanks. Bob
I noticed the following gem in David Benson's (email@example.com.WSU.EDU) posting about Congress finding bugs in software... > the Hubble Space Telescope of the B1-B Bomber, for example ... Now I neither do work on the HST, or the B1-B, but I know something of both systems. I would suggest to Congress, Mr. Benson, or the author of the AAAS article (which ought to know better), that mounting the HST on the B1-B (I would guess as a bomb sight, having no other conceivable purpose by my guess) is, uh, overkill? ;-) [The original _Science_ article by M. Mitchell Waldrop of course says "the Hubble Space Telescope or the B1-B Bomber, for example ..." PGN]
Please report problems with the web pages to the maintainer