In last month’s column, I mused about how, in software as in life itself, there’s usually a time for an action and also a time for its opposite. This month, I want to discuss the opposite of that thought, by which I mean events for which there is never a time.

I often compare our software industry to the medical industry. A doctor can’t completely control a patient’s outcome. Medical situations vary, risks always exist, stuff happens. But certain patient-harming events should never, ever occur. We know what causes them, we know how to prevent them; therefore, their occurrence always constitutes malpractice. Reading the list of these “never events” (bit.ly/h9RMl8) makes you wince: operating on the wrong patient, or on the wrong part of the correct patient; leaving surgical instruments inside the patient and so on. My all-time favorite good news/bad news joke—“The bad news is that we amputated the wrong leg. The good news is that your other leg is getting better after all”—brutally illustrates the unacceptability of these events. (I know: “Plattski, you are one sick puppy.” It’s been said before.)

We need to adopt this same idea for our software: that certain occurrences are never, ever, acceptable. We need to define these events, publicize them and educate developers about what they are and how to avoid them. And we need to explain to users that they should never have to tolerate this behavior from their software and shouldn’t be asked to.

Here’s my first proposed never event for software. We wish our programs wouldn’t crash, as doctors wish their patients wouldn’t die (and they envy our reset buttons), but neither is going to happen anytime soon. Because we know that our programs will occasionally crash, I say that losing a user’s work in a crash is a never event. Remember how you’d work in Word or Excel for two hours, then up would pop the dreaded Unrecoverable Application Error box and it was all gone? Not acceptable. Ever. No matter what.

I hear lazy geeks objecting. “That’s not our problem, it’s a matter of education. Users just have to save their work every 10 seconds, then they’ll never lose anything.” Balderdash. That’s not the user’s job, any more than it’s the patient’s job to tell the surgeon: “No, you dimwit, it’s my other arm. Are you sure you remember which end of the scalpel to hold?” It’s the surgeon’s job to get the operation right, as it is ours to get the software right.

Because these events should never occur, it’s a big story when they do. Consider respected surgeon David Ring, who operated on the wrong hand of one of his patients at Massachusetts General Hospital (and performed the wrong procedure, too). Rather than cover it up, or discuss it only in a closed mortality and morbidity conference, he published his own case in the prestigious New England Journal of Medicine (bit.ly/gzWN9q). The surgical team performed a full failure analysis to find the root cause. (It’s far more complicated than you might think; read the article.) They reviewed protocols and changed some of them: for example, the alcohol prep that washed away the supposedly indelible surgical site markings was discontinued. The world is a better place for this intolerance of unacceptable events, and for the openness in dealing with those that manage to occur.

Our industry needs the same thing. Why was data lost? It shouldn’t have been. Was the disk full? That’s a capacity problem—we know how to solve that. Because some dimwit yanked the plug out of the wall? That’s a durability problem—we know how to solve that, in several different ways at different price points. Because we forgot to check a null pointer? Easily solvable. And so on.

If our profession is ever to take its rightful place as a pillar of society, we need to adopt this idea from another pillar.

What do you think are the never events in software, and how should we prevent them? Use the link at the end of my bio to tell me. As always, readers will be identified only by first names, unless they request otherwise.

David S. Platt teaches Programming .NET at Harvard University Extension School and at companies all over the world. He’s the author of 11 programming books, including “Why Software Sucks” (Addison-Wesley Professional, 2006) and “Introducing Microsoft .NET” (Microsoft Press, 2002). Microsoft named him a Software Legend in 2002. He wonders whether he should tape down two of his daughter’s fingers so she learns how to count in octal. You can contact him at rollthunder.com.

Des letzten Monats mused ich dazu, wie in Software wie im Leben selbst in der Regel eine Zeit für eine Aktion und auch eine Zeit für das Gegenteil ist. In diesem Monat möchte ich das Gegenteil von diesen Gedanken zu diskutieren, von denen ich Ereignisse bedeuten für die es nie eine Zeit ist.

Ich vergleichen oft Sie unsere Softwarebranche des Wirtschaftszweigs der medizinischen. Ein Arzt kann nicht des Patienten Ergebnis vollständig gesteuert werden. Medizinische Situationen variieren, Risiken immer vorhanden, Stuff geschieht. Aber Patienten schädigen Auftreten bestimmter Ereignisse sollten nie, nie. Wir wissen, dass diese Ursachen, wir wissen, wie man Sie verhindert;ihres Auftretens immer bildet daher falschem Verhalten. Lesen die Liste dieser "nie Events" (bit.ly/h9RMl8) macht Sie wince: auf den falschen Patienten oder auf den falschen Teil der richtigen Patienten;chirurgische Instrumente innerhalb der Patient verlassen usw.. Meine Schulungsniveau bevorzugten gute und eine schlechte Neuigkeiten Witz – "die schlechte Nachricht ist, dass wir die falschen bEin amputated. Die gute Nachricht ist, dass Ihre anderen bEin immerhin noch besser ist "– schonungslos die Beurteilung dieser Ereignisse veranschaulicht. (Ich weiß: "Plattski, Sie sind ein kranker Welpe." Es ist vor dem gesagt wurde.)

Wir brauchen diese dieselbe Idee für unsere Software bringt:, dass bestimmte Ereignisse nie, nie, zulässig sind. Wir müssen diese Ereignisse definieren, diese publicize und informieren Sie die Entwickler über Was sind und ihre Vermeidung. Und wir müssen den Benutzern erklären, dass Sie sollten nie dieses Verhalten aus Ihrer Software zu tolerieren und sollte nicht aufgefordert werden.

Hier ist meine erste nie Ereignis für Software vorgeschlagen. Wir möchten unsere Programme wouldn't stürzt ab, wie Ärzte möchten Patienten die wouldn't (und Sie beneiden unser Rücksetz-Schaltflächen), aber keiner so schnell erfolgen soll. Da wir wissen, dass unsere Programme stürzen gelegentlich, ich sage, Datenverlusten des Benutzers bei einem Absturz ist eine nie Ereignis. Beachten Sie, wie Sie in Word oder Excel innerhalb von zwei Stunden arbeiten würde, dann pop-up würde das gefürchtete nicht behebbarer Anwendungsfehler-Feld, und es war alles verschwunden? Nicht annehmbar. Jemals. Egal, was.

Ich höre lazy Geeks kannte. "Das ist nicht unser Problem, es ist eine Frage der Bildung. Benutzer haben einfach, Ihre Arbeit alle 10 Sekunden, und Sie verlieren niemals irgendetwas." Balderdash. Das ist nicht der Benutzer Auftrag, mehr als die der Patient Auftrag anzuweisen, den Surgeon: "Nein, Sie Dimwit, es ist mein andere Arm. Sind Sie sicher, dass Sie sich erinnern welches Ende der Skalpell zu halten?" Es handelt sich um die Surgeon-Auftrag den Vorgang rechts und erhalten, da es uns, die Software richtig hinzubekommen.

Da diese Ereignisse nie auftreten sollte, ist es eine große Geschichte in diesem Fall. Sollten Sie anerkannten Surgeon David Ring, wer betrieben Falscher Lagerbestand eines seiner Patienten am Massachusetts General Hospital (und geschickten Blutproben zu durchgeführt). Anstatt die Abdeckung nach oben, oder diskutieren, die sich nur in einer geschlossenen Mortalität und Morbidität Konferenz, veröffentlichte er seinen eigenen Fall in der renommierten New England Journal of Medicine (bit.ly/gzWN9q). Das chirurgische Team durchgeführt, eine vollständige Fehleranalyse, um die Ursache zu finden. (Es ist weit mehr kompliziert als Sie vielleicht denken.Lesen Sie den Artikel.) Diese Protokolle überprüft und einige von Ihnen geändert: z. B. die Vorbereitung von Alkohol, die die Auswahlmöglichkeiten angeblich unverwischbar chirurgische Site sofort gewaschen wurde eingestellt. Die Welt ist, einen besseren Ort für diese Intoleranz inakzeptabel Ereignisse und der Offenheit im Umgang mit Verwalten von auftreten.

Unsere Branche braucht das gleiche. Warum wurde Daten verloren? Es sollte nicht gewesen. War der Datenträger voll? Das ist ein Problem der Kapazität – wir wissen, wie, zu lösen. Da einige Dimwit des Steckers von der Wand yanked? Das ist ein Problem für die Dauerhaltbarkeit – wir wissen, wie, die auf verschiedene Weise zu einem anderen Preis zu lösen. Weil wir vergessen, haben um einen null-Zeiger zu überprüfen? Schnell lösbar. Und so weiter.

Wenn unser Berufsstand jemals seine rechtmäßige als ein Pfeiler der Informationsgesellschaft stattfinden, müssen wir diese Idee von einem anderen Pfeiler zu erlassen.

Was Sie tun, denken sind die nie Ereignisse in der Software, und wie sollten wir Sie hindern? Verwenden Sie den Link am Ende meiner Bio, um zu erfahren. Leser werden wie immer nur nach den Vornamen, identifiziert werden, es sei denn, diese anderweitig zu erlangen.

David S.Platt vermittelt Programmierung.NET Extension-Schule der Harvard University und in Unternehmen überall auf der Welt zu Er ist Autor von 11 programming Bücher, einschließlich "Warum Software Spam" (Addison-Wesley Professional, 2006) und "Introducing Microsoft."NET" (Microsoft Press, 2002). Microsoft namens ihm eine Software-Legende in 2002.Er fragt sich, ob er zwei Fingern seiner Tochter Band sollten, damit er eine Oktalzahl zählen lernt. Sie erreichen ihn unter rollthunder.com.