The hospital metaphor

In the Google Testing blog last month, James A. Whittaker introduced a pretty interesting look at testing using a metaphor of hospital/medical practices versus the traditional manufacturing one: http://googletesting.blogspot.com/2010/02/testing-in-data-center-manufacturing-no.html

Here is a quote from the article about the life of a tester: "In our father's software and Deming's model we talk about quality control and quality assurance while we play the role of inspector. In contrast, my job seems much more like that of an attending physician. In fact, a medical analogy gives us some interesting parallels to think about software testing. A physician's hospital is our data center, there is always activity and many things are happening in parallel. Physicians have patients; we have applications and features. Their medical devices are our infrastructure and tools. I can picture my application's features strewn across the data center in little virtual hospital beds."


While I had never explicitly made this analogy before reading this, it seems to fit with my current perspectives. When I first started thinking about the team organization for the recent startup that I was involved with, the first position I hired was that which I had an easy time picking, but a tough time naming; a hybrid of a testing, QA, product specialist, release specialist,  coordinator... all rolled into one. Eventually, as the business grew, I knew that specific areas of this person's responsibilities would be filled by multiple people. I knew immediately who I wanted for this position, and that it was the first most important role I needed to fill but I didn't know what title to give her. I'm still not sure what the best title is for this person, but I now have an analogy for the environment I was trying to create to foster our software's success ... and that was more of a hospital, and less of a manufacturing plant. Therefore, who I hired first was a hospital administrator.

I knew that as we brought on developers we would have various feature branches being worked on simultaneously. Sadly, some of these feature branches might not ever see production. Following on the idea that software is "grown" not "built", not all of these feature branches were even all that well described before being birthed. But, in order to have a hope of someday growing to reach production, they would need a hospital bed, an attending staff to watch over vitals, care for their needs, attending physicians to diagnose issues and coordinate treatment, and surgeons to remove disease and problem areas. It takes a lot of coordination, effort and loving care to keep these projects on a road to production. And a hospital administrator is this coordination glue.

I've worked in a lot of different software development environments. I've seen environments where there is no hospital, and the little software feature branches get pushed out of the nest right from birth to production. I've seen environments that have testing and QA labs, but the entire department is considered entry level. Would you want to put your child's care in a hospital that was considered full of "entry level" people? I think the traditional manufacturing analogy breads some of this thought; regardless if it really fits with real manufacturing QA and testing. 


The old manufacturing analogy makes us think that testing is part of an assembly line. Things are built and assembled at one point on the line, and then tested at another point, and then shipped at another, etc. It also makes us think that because its part of an assembly line, people can quickly be trained to do specific tests repeatedly over and over as the product passes through. However, software doesn't just pass through like parts. Software is much more of an organic thing and its success depends upon environments that foster organic health. As James suggest in the article, "Software isn't so much built as it is grown. "


I think the hospital metaphor fits much better then the manufacturing one because of the organic nature of software. I like how James describes his role of a tester as more akin to that of an attending physician. I like how the hospital metaphor helps me better quantify this "hospital administrator" role that I've been finding so important in today's software development lifecycle. It also helps me identify some of the missing pieces in many software development environments that I've been part of. There is one particular piece to the puzzle that the hospital metaphor fills in nicely (in addition to the hospital administrator) that has been on my mind a lot lately. But, I'll let the overall hospital metaphor take shape for a few days and say more about that other idea next.