The Black Liszt

What Can Software Learn from Steamboats and Antiseptic Surgery?

Software is among the most advanced, rapidly changing fields of technology. Only the "kids" who grew up with the latest techniques seem to be able to master them. At the same time, really bad ideas spread through software groups like the plague; they take hold and resist cure, in spite of producing terrible results. How can we make sense out of a field that advances rapidly and resists change at the same time?

History

As I've pointed out, software people are strongly averse to learning about computer history. In some fields (e.g. physics), the very terms used are named after historical figures; in others, history is treated with reverence (e.g., Santayana: "Those who cannot remember the past are condemned to repeat it."); in software, by contrast, we use the phrase "that's history" to dismiss anything that happened in the past as obviously irrelevant to the present.

I think studying history is the only way to understand the present, software included. I think we can understand the strange software phenomenon of rapid change combined with resistance to change by taking two examples from history: one in which new methods in technology were rapidly accepted by all concerned parties, and the other in which clearly superior new methods were resisted for many long years by the leading people in the field.

Steamboats

It would be great if software advances were adopted quickly, like the way steam technology rapidly overcame wind as a method for moving boats.

The displacement of wind by steam is clearly laid out in T.J. Stile's excellent biography of one of the major figures in the transformation, Cornelius Vanderbilt.

Vanderbilt started in business by running a sailing-boat "taxi" service from Staten Island to Manhattan. He transitioned into the rapidly emerging steam boat transportion business, not only as a captain and owner, but (surprisingly to me) as an engineer.

The public took to the new steamboats quickly. The reason is clear: speed. There was, at the time, no quicker way to get from point A to point B if there were a water route between them. The speed of the boat was immediately obvious to the simple observer, and easy to verify by noting departure and arrival times. To prove whose boat was the fastest, there were races.

Vanderbilt's steamboats were judged by a clear standard: whose was the fastest? The criteria were easy to measure.

Antiseptic Surgery

The benefits of antiseptic surgery, as introduced by Joseph Lister, were clear: instead of a large number of patients dying of infection after surgery, they would live. Ego clearly played a role in resisting the adoption of the new method. But, to be fair, there is another important factor.

What made surgery different from steamboats? They were both major technical advances. They both involved major changes in what you did and how you did it -- more so with boats than with surgery! So why did steam catch on quickly, even though they required whole new boats of radically different design and operation, while the antiseptic method was resisted for decades, even though it was subsidiary to the surgery itself, which was left largely unchanged?

Boats and Surgery

The fact that steamboats were faster than sailboats was easy and unambiguous to measure, while the surgery outcomes were difficult and ambiguous to measure.

The time of each boat trip is easy to measure. It's just a time duration. When you watch two boats, anyone can see which one moves more quickly. By contrast, every surgery is different. The patient is different, the trouble being fixed is different, and the ultimate outcome may not be determined for weeks. Many surgery patients continued to die with antiseptic methods because it wasn't the only factor influencing the outcome. Furthermore, excellent surgeons who were dirty could save patients that would have been killed by crappy surgeons who happened to use antiseptic methods, since after all not every patient got infected.

In retrospect, it's completely maddening that surgeons failed to be swayed by the arguments and evidence in favor of Lister's carbolic acid methods, and ego certainly played a role. But the case of the rapid acceptance of the more radical change to steam in boats makes it clear that something more than ego is at work here. Simply put, it is how comparable and measurable are the outcomes of the new technology? With steamboats, you can tell the difference in seconds with the naked eye, and verify it with a stopwatch. No arguments. With surgery, the cases are not clearly and unambiguously comparable, statistics are needed, and there is major variability. There is room for arguments.

Software, steamboats and antiseptic surgery

Is any given advance in software like moving from sailboats to steamboats, or is it more like adding antiseptic methods to surgery?

That's easy: unlike straightforward competitions like races, every software project is different. In a race, the competitors take off from a starting line at the same time, and whichever crosses the finish line first is the winner. Simple! But in the real world of software, every project is different; you can always point to differences in requirements, conditions, deployment, or other things to explain why this project took more time and resources than that project. It sounds like software is kind of like surgery!

Conclusion

It is my personal experience and judgment that ego can play a significant role in explaining why many software groups stay mired in the same old methods, getting the same lousy results, year after year. But I think that if software projects were as comparable as transportation schedules, the evidence would simply force more rapid change, like it or not, on intransigent software groups. But because of how genuinely challenging it is to compare software projects to each other, it is at least understandable how only the most enterprising and eager-to-be-the-best software groups seek out and adopt the very best methods. 

A Lesson from Joseph Lister: Ego, the Killer of Software Projects

In the 1880's, American surgeons lost a large fraction of their patients to post-operative infection, including assasinated president James A. Garfield. They simply refused to adopt the antiseptic methods pioneered by Joseph Lister, although those methods were thoroughly documented and proven. In the 2010's, programmers fail to effectively complete a large fraction of their software projects, including ones that are essential to the survival of the organizations that employ them. They, and the educators who train them, simply refuse to adopt effective methods of modern software development. What is the common thread? Ego.

Joseph Lister

Lister was far more significant than the source of the name for the mouthwash Listerine.

A surgeon at the University of Glasgow, he read the work of Louis Pasteur, who showed that rotting and fermention were due to micro-organisms. After confirming Pasteur's results with his own experiments, Lister experimented with antiseptic techniques for treating wounds.

Lister found that carbolic acid solution swabbed on wounds remarkably reduced the incidence of gangrene. In August 1865, Lister applied a piece of lint dipped in carbolic acid solution onto the wound of an eleven year old boy at Glasgow Infirmary, who had sustained a compound fracture after a cart wheel had passed over his leg. After four days, he renewed the pad and discovered that no infection had developed, and after a total of six weeks he was amazed to discover that the boy's bones had fused back together, without the danger of suppuration.

Lister wrote papers, a book, and did his best to spread the word of his life-saving technique.

The Doctors' Response

You would think that doctors would have quickly and enthusiastically adopted the antiseptic method to help improve their awful survival rates. But you know what actually happened. As described in her excellent book, Candice Millard tells the story:

Although the results were dramatic -- the death rate among Lister's surgical patients immediately plummeted -- antisepsis had provoked reactions of deep skepticism, even fury. In England, Lister had been forced repeatedly to defend his theory against attacks from enraged doctors. "The whole theory of antisepsis is not only absurd," one surgeon seethed, "it is a positive injury." Another charged that Lister's "methods would be a return to the darkest days of ancient surgery."

Things got better in Europe. But not in the US.

By 1876, Lister's steady and astonishing success had silenced nearly all of this detractors at home and in Europe. The United States, however, remained inexplicably resistant. Most American doctors simply shrugged off Lister's findings, uninterested and unimpressed. Even Dr. Samuel Gross, the president of the Medical Congress and arguably the most famous surgeon in the country, regarded antisepsis as useless, even dangerous. "Little, if any faith, is placed by any enlightened or experienced surgeon on this side of the Atlantic in the so-called carbolic acid treatment of Professor Lister," Gross wrote imperiously.

James A. Garfield

Garfield was one of the most extraordinary men ever elected president. He was shot in the back four months after being inaugurated in 1881, which is the event that brings us to Lister.

In short, had he been under the care of English or European doctors, he would almost certainly have survived the attack.

The Medical Treatment of Garfield

This site provides a summary of what happened:

The first doctor on the scene administered brandy and spirits of ammonia, causing the president to promptly vomit. Then D. W. Bliss, a leading Washington doctor, appeared and inserted a metal probe into the wound, turning it slowly, searching for the bullet. The probe became stuck between the shattered fragments of Garfield's eleventh rib, and was removed only with a great deal of difficulty, causing great pain. Then Bliss inserted his finger into the wound, widening the hole in another unsuccessful probe. It was decided to move Garfield to the White House for further treatment.

Leading doctors of the age flocked to Washington to aid in his recovery, sixteen in all. Most probed the wound with their fingers or dirty instruments. Though the president complained of numbness in the legs and feet, which implied the bullet was lodged near the spinal cord, most thought it was resting in the abdomen. The president's condition weakened ... It was decided to move him by train to a cottage on the New Jersey seashore.

Shortly after the move, Garfield's temperature began to elevate; the doctors reopened the wound and enlarged it hoping to find the bullet. They were unsuccessful. By the time Garfield died on September 19, his doctors had turned a three-inch-deep, harmless wound into a twenty-inch-long contaminated gash stretching from his ribs to his groin and oozing more pus each day. He lingered for eighty days, wasting away from his robust 210 pounds to a mere 130 pounds. The end came on the night of September 19. Clawing at his chest he moaned, "This pain, this pain," while suffering a major heart attack. The president died a few minutes later.

A whole nation of doctors simply ignored the evidence of the effectiveness of Lister's methods. Lister himself came to America and lectured on them, and American doctors were well aware of the methods. Full of themselves and comfortable in their ways, they continued wantonly killing patients who could have lived -- including President Garfield.

Antiseptic techniques and Software

What can possibly account for this behavior? I know one answer, because I see the equivalent in software groups all too frequently. Put simply, it's ego.

Each group, and particularly its leader, is convinced that they're doing the best possible job that can be done, against steep obstacles. They feel starved for resources, pressed for time, but nonetheless performing at a very high level. They are educated, experienced, and feel they've made the best possible choices of tools, methods, designs and architectures.

Somehow, the leader or someone in the group hears about something new that's supposed to be really effective for tasks like theirs. Maybe they hear about it from some know-it-all who's somehow associated with investors, or someone else they are "supposed" to listen to.

In my experience, the reaction of the software group is nearly identical to that of the American doctors. Whatever the new thing (tool, method, technique, design, architecture), it can't possibly be as good as what they're already doing. Even when they hear stories about great results, they are deeply skeptical, and are convinced that their own methods are still better. Period. Why, to consider the possibility that someone else is doing things better than they are implies that they are not the best at what they do. Impossible!

What explains this profound lack of interest? While other factors are sometimes involved (I'll explore them another time), it's hard to discount the impact of human ego, pure and simple.

Architect Bjarke Ingels on Software

The most prestigious role you can normally have in a software group is that of "architect." Bjarke Ingels is a rapidly rising star in the realm of physical-world architecture. So naturally I was on alert when he made an off-hand comment about software.

B.I.G.

The Bjarke Ingels Group has built high-profile projects all over the world. For example, here

is a view of a building they're designing in Manhattan. They've made a little movie about it that gives a good perspective view as well.

A profile about the architect and his work just appeared in the WSJ. While talking about the challenges involved in the project depicted above, he said the following:

"I like complexity, but I like it in the real meaning of the word, as the opposite of complication," Mr. Ingels says. "In computer programming, you try to transmit the most information with the fewest lines of code. With buildings, it's the same: Complexity is a child of simplicity. You want to create as much quality with a minimum amount of effort."

This blew my mind: "you try to transmit the most information with the fewest lines of code." It blew my mind not because it's new (to me), but because it's simple, it's elegant, it's concise, and it expresses a deep truth about programming heard all too rarely from people involved with computers.

What usually happens when "software architects" get involved with software is that more code is written that somehow manages to get less done. They have all sorts of reasons why they think that's a good thing, except they're usually wrong.

Here's a thought: maybe we should send our software architects to "real" architecture school. If anything like Bjarke Ingels is the result, we'll be better off.