A physician’s son | The Observation Deck

My father is an emergency medical physician, a fact that has had a subtle but discernable influence on my career as a software engineer. Emergency medicine and software engineering are of course very different problems, and even though there are times when a major and cascading software systems failure can make a datacenter feel like an urban emergency room on a busy Saturday night, the reality is that if we software engineers screw up, people don’t generally die. (And while code and machine can both be metaphorically uncooperative, we don’t really have occasion to make a paramedic sandwich.) Not only are the consequences less dire, but the underlying systems themselves are at opposite ends of a kind of spectrum: one is deterministic yet brittle, the other sloppy yet robust. Despite these differences, I believe that medicine has much to teach us in software engineering; two specific (if small) artifacts of medicine that I have incorporated into my career:

Morbidity and mortality. M&M is one of the most sacred rites of modern medicine: a regular meeting (often every week) in which physicians (and physicians alone) discuss – in detail – every case of morbidity or severe complication on their watch since the last meeting. The purpose of this meeting is to learn from failure, and physicians in M&M are brutally honest with themselves and their peers to determine what happened and why – and if any other outcome was possible. Engineering often stands to benefit from this same kind of rigorous self-examination, and at Sun, I initiated the Kernel Technical Discussions to be allow such a forum. My inspiration for this was very much M&M, but the meeting quickly shifted to reflect the natural forward-looking disposition of engineers: KTDs were used much more frequently to discuss the details of some technology in development than to analyze defects in the system and address systemic (and especially, human) failure. And it may well be that the discipline is still moving too quickly to broadly merit M&M – but I think many software engineering organizations would stand to benefit be examining what went so horribly wrong and why.
Journal Club. A Journal Club is simply a regular meeting (often monthly) of practitioners to discuss research articles, with a particular eye to the impact on their daily work. Journal Club is not unique to medicine – many academic departments (and especially the biosciences) have similar or identical constructs – but its roots are in medicine, and its bias remains to inform the practitioner of published research. In my father’s emergency department, Journal Club was a monthly event hosted in the evening at the house of one of the attending physicians, with the host responsible for supplying food and drinks for the fifty or so attendees of the 2-3 hour meeting. For my sister and me, Journal Club at our house was a kind of annual holiday, for it represented the one sanctioned vector by which soda pop (an otherwise forbidden nectar) found itself in the fridge – seemingly by the ton.

At Joyent, I have instituted a regular Journal Club meeting. It’s still nascent, and we’re still finding our footing a bit, but so far it has spurred some interesting conversation. In particular, we have engineering participants from across the company (development, operations and support), and have found Journal Club to be a forum (and discussion of research papers a vector) for healthy cross-organizational communication. So far we have discussed James Hamilton’s excellent (and influential) On Designing and Deploying Internet-Scale Services and Benson et al.’s A First Look at Problems in the Cloud, a paper that was as thought-provoking for its limitations as for its strengths. This will continue to be a regular (monthly) event at Joyent, and I believe that it will bear fruit in terms of more informed engineering – be it in terms of development, operations or support.

M&M and Journal Club are two ways that medicine has influenced software engineering (or mine, anyway); what of the influences of information systems on the way medicine is practiced? To explore this, we at ACM Queue sought to put together an issue on computing in healthcare. This is a brutally tough subject for us to tackle – what in the confluence of healthcare and computing is interesting for the software practitioner? – but we felt it to be a national priority and too important to ignore. It should be said that I was originally introduced to computing through medicine: in addition to being an attending physician, my father – who started writing code as an undergraduate in the 1960s on an IBM System/360 Model 50 – also developed the software system that ran his emergency department; the first computer we owned (a very early IBM PC-XT) was bought to allow him to develop software at home (Microsoft Pascal 1.0 FTW!). I had intended to keep my personal history out of the ACM discussion, but at some point, someone on the Board said that what we really needed was the physician’s perspective – someone who could speak to the pracitical difficulties of integrating modern information systems into our healthcare system. At that, I couldn’t hold my tongue – I obviously knew of someone who could write such an article…

Dad graciously agreed, and the resulting article, Computers in Patient Care: the Promise and the Challenge appears as the cover story on this month’s Communications of the ACM. I hope you enjoy this article as much as I did – and who knows: if you are developing software that aspires to be used in healthcare, perhaps it could be the subject of your own Journal Club. (Just be sure to slip the kids a soda or two!)