James, you are poet and a philosopher. You could have enriched the world's greatest libraries with your treatise on human condition. What are you doing as a tester? Why James, why?
So I'm not the only one who sees the hospital analogy!
What I find interesting is this: hospitals on TV always seem to be run by doctors (see MASH, Scrubs, Grey's Anatomy, House...). And yet very, very few of the software projects I've been on were run by software developers. In dozens of projects I've worked on the project managers were almost always MBA types. One project I was on was managed by a marketing major. Very few of those managers had much, if any, experience writing code.
Granted, I'm drawing a parallel with television pseudo-reality. Maybe the idea that hospitals are run by old, grizzled veteran doctors doesn't hold water. But the analogous setup sure seems to work better for software.
Interesting analogy. As a "doctor", I often feel like there is a health insurance bureaucracy questioning my practices and wanting me to treat every patient the same. And don't forget the pharmaceuticals companies trying to convince me that their magic pills will cure our patients.
James - as one who has led testing for Electronic Medical Record apps, I appreciated your take. In this space there is less 'building' of new code-based functions and more connecting of existing toolsets. This industry tends to late adoption of new approaches/techniques. So hurry up and get real-time monitoring of test procsses hammered out. We'll see it about 2-3 years from now.
Deming still applies to software development and testing, but not Deming as applied to manufacturing. Deming as applied to product development is perfectly consistent with your observations.
I agree with the manufacturing-no-more thing, but I think it's a mistake to couple Deming to manufacturing just because software people mistakenly saw software development as manufacturing and proceeded to collude that with Deming.
Realizing that software development isn't manufacturing is a great step forward. Perspectives like flow-based product development management reflect these realizations, but don't conclude that Deming is obsolete. They conclude that our presumption that software development is manufacturing was never correct.
Deming is still applicable to product development, but we have to realize that we're doing product development.
This has been an uncanny week or two in software testing for me, and it includes your post. As the whole Toyota debacle has been unfolding, I've been in the midst of reading "Artful Making" by Austin and Devin. (Your CEO wrote the forward) It mentions Deming in several places. Your post indicates that you feel the ground shifting beneath our definitions of software engineering, development and testing? I do as well.
A very interesting analogy between medicine and software testing To carry this further:
I) Software testing
A) System testing is like doing a master health check up for a human being You run through a pre determined set of tests, designed to check that every functionality of the software / human being works well. The extra point: At a particular age the human being is more prone to certain diseases (cardiac, blood pressure, eye sight..) – the health checkup will also be designed accordingly - What is similar in the case of software? Modifications in a software are likened to aging - modifications are of two forms – a) handling bugs, primarily during initial development – changing the code to handle the bugs initially found and also bugs found after release b) after the software has been released - to handle new features; Each of these ‘aging’ have to be handled differently - type a - handled by feature tests and more importantly - regression tests while type b is handled by feature tests primarily, then by integration tests and less by regression tests.
B) Unit testing is like doing a particular human organ functionality tests (like doing eye tests or checking for blood pressure) Here the requirements are spelt out in detail and particular tests are carried out to check these extreme situations are acceptable by the tested unit / organ
C) A fault is reported on the field in the software – Now similar to an emergency situation in the hospital the test engineer should be able to narrow down the reported fault to possible scenarios and reproduce the fault within the test environment - providing a means for the developer to then identify the module(s) that is faulty and how and rectify it - also providing a means to test that the fault is now handled.
And yes we need to keep track of the history of the patient (bugs in a particular software, to aid regression testing), the group of patients (bugs in the type of software being tested – similar bugs are likely in certain scenarios – test patterns!), and the environment where the patient lives in (bugs in the accessory software that the software being tested, interacts with)
Your analogies explained the use of "Engineering Analytics" in an original and refreshing way. However, in most of the modern data center applications, not only the data flows through the veins of the Apps but the App itself gets patched. Using your analogy -- think of it as a patient getting blood transfusion as well as organ patching while adding a couple or more new limbs to the body !!.
It would be a great thing if one can not only visualize the path coverage of the App with real-time data in the data centers but also distinguish how much of that is going through "aged" code vs newly "patched" code.
Regarding your Deming's reference, you have almost "Glenn Becked" ;)
Definitely a thought-provoking post. I really like the analogy between the medical and software fields. Especially the part about testers collaborating with each other and sharing the thoughts of an application. However, the thoughts that come out from a practical point of view make me wonder as to what should be contents of the medical clipboard. Is it an indication of the problematic areas of the software? Is it general notes about every single part of the application under test? Is it notes of the "we've been here, we've tested that" nature? Or maybe it's a combination of all.
Matt Doar wrote: "In real life, hospitals are *not* run by doctors."
And that's a pity, isn't it? My experience with software development is that having managers who are completely inexperienced in the field practiced by the people they manage results in very poor management decisions.
Back to James' original post: I'm not sure that "creator" is the right place to put developers in the analogy. Certainly they are present and instrumental in the "birth" of software. But I wouldn't say a developer's role in creation is their primary function on a software project. Reaching again into my own experiences, I spend far more time fixing and enhancing existing software than creating brand new software.
Software just sort of happens under the right circumstances, if steps aren't taken to prevent it. We developers may help to bring about those circumstances sometimes, but mostly we seem to work to bring software to maturity, keep it going for a few years, and then ease it into end of life. I'm not sure what that makes us.
Rather than "creator", maybe we can call developers their intellectual "parents"? They should know the most about the applications, obviously, but perhaps not all their extra-curricular activities?
I feel that extends the metaphor for their involvement in treatment as well. ;)
Hi James, Interesting analogy, keep updating. These kind of analogy are rare to find on Internet, yaap you need to dive deep into the subject to get through it.
James, you are poet and a philosopher. You could have enriched the world's greatest libraries with your treatise on human condition. What are you doing as a tester? Why James, why?
SvarSletSo I'm not the only one who sees the hospital analogy!
SvarSletWhat I find interesting is this: hospitals on TV always seem to be run by doctors (see MASH, Scrubs, Grey's Anatomy, House...). And yet very, very few of the software projects I've been on were run by software developers. In dozens of projects I've worked on the project managers were almost always MBA types. One project I was on was managed by a marketing major. Very few of those managers had much, if any, experience writing code.
Granted, I'm drawing a parallel with television pseudo-reality. Maybe the idea that hospitals are run by old, grizzled veteran doctors doesn't hold water. But the analogous setup sure seems to work better for software.
Excellent post! It's not often I hear a new (to me) analogy about software development. And I like the one of health care.
SvarSletInteresting analogy. As a "doctor", I often feel like there is a health insurance bureaucracy questioning my practices and wanting me to treat every patient the same. And don't forget the pharmaceuticals companies trying to convince me that their magic pills will cure our patients.
SvarSletJames - as one who has led testing for Electronic Medical Record apps, I appreciated your take. In this space there is less 'building' of new code-based functions and more connecting of existing toolsets. This industry tends to late adoption of new approaches/techniques. So hurry up and get real-time monitoring of test procsses hammered out. We'll see it about 2-3 years from now.
SvarSletWow. Great analogy. Wonder if this should be a pattern similar to the Gang of Four' other ones?
SvarSletDeming still applies to software development and testing, but not Deming as applied to manufacturing. Deming as applied to product development is perfectly consistent with your observations.
SvarSletI agree with the manufacturing-no-more thing, but I think it's a mistake to couple Deming to manufacturing just because software people mistakenly saw software development as manufacturing and proceeded to collude that with Deming.
Realizing that software development isn't manufacturing is a great step forward. Perspectives like flow-based product development management reflect these realizations, but don't conclude that Deming is obsolete. They conclude that our presumption that software development is manufacturing was never correct.
Deming is still applicable to product development, but we have to realize that we're doing product development.
This has been an uncanny week or two in software testing for me, and it includes your post. As the whole Toyota debacle has been unfolding, I've been in the midst of reading "Artful Making" by Austin and Devin. (Your CEO wrote the forward) It mentions Deming in several places. Your post indicates that you feel the ground shifting beneath our definitions of software engineering, development and testing? I do as well.
SvarSletA very interesting analogy between medicine and software testing
SvarSletTo carry this further:
I) Software testing
A) System testing is like doing a master health check up for a human being
You run through a pre determined set of tests, designed to check that every functionality of the software / human being works well.
The extra point: At a particular age the human being is more prone to certain diseases (cardiac, blood pressure, eye sight..) – the health checkup will also be designed accordingly - What is similar in the case of software?
Modifications in a software are likened to aging - modifications are of two forms – a) handling bugs, primarily during initial development – changing the code to handle the bugs initially found and also bugs found after release b) after the software has been released - to handle new features;
Each of these ‘aging’ have to be handled differently - type a - handled by feature tests and more importantly - regression tests while type b is handled by feature tests primarily, then by integration tests and less by regression tests.
B) Unit testing is like doing a particular human organ functionality tests (like doing eye tests or checking for blood pressure)
Here the requirements are spelt out in detail and particular tests are carried out to check these extreme situations are acceptable by the tested unit / organ
C) A fault is reported on the field in the software – Now similar to an emergency situation in the hospital the test engineer should be able to narrow down the reported fault to possible scenarios and reproduce the fault within the test environment - providing a means for the developer to then identify the module(s) that is faulty and how and rectify it - also providing a means to test that the fault is now handled.
And yes we need to keep track of the history of the patient (bugs in a particular software, to aid regression testing), the group of patients (bugs in the type of software being tested – similar bugs are likely in certain scenarios – test patterns!), and the environment where the patient lives in (bugs in the accessory software that the software being tested, interacts with)
Very thought provoking and original. It resonates greatly with our approach to testing the website here at Netflix.
SvarSletMetaphors are the problem, not the solution.
SvarSletIsaac wrote: "What I find interesting is this: hospitals on TV always seem to be run by doctors"
SvarSletIn real life, hospitals are *not* run by doctors. The doctors get to sit in committees with managers, and the managers run the hospitals.
Your analogies explained the use of "Engineering Analytics" in an original and refreshing way. However, in most of the modern data center applications, not only the data flows through the veins of the Apps but the App itself gets patched. Using your analogy -- think of it as a patient getting blood transfusion as well as organ patching while adding a couple or more new limbs to the body !!.
SvarSletIt would be a great thing if one can not only visualize the path coverage of the App with real-time data in the data centers but also distinguish how much of that is going through "aged" code vs newly "patched" code.
Regarding your Deming's reference, you have almost "Glenn Becked" ;)
Hi James,
SvarSletDefinitely a thought-provoking post. I really like the analogy between the medical and software fields. Especially the part about testers collaborating with each other and sharing the thoughts of an application. However, the thoughts that come out from a practical point of view make me wonder as to what should be contents of the medical clipboard. Is it an indication of the problematic areas of the software? Is it general notes about every single part of the application under test? Is it notes of the "we've been here, we've tested that" nature? Or maybe it's a combination of all.
I can understand your analogy with medical environment, altough I feel that is too much metaphore and too few real/practical examples.
SvarSletMatt Doar wrote: "In real life, hospitals are *not* run by doctors."
SvarSletAnd that's a pity, isn't it? My experience with software development is that having managers who are completely inexperienced in the field practiced by the people they manage results in very poor management decisions.
Back to James' original post: I'm not sure that "creator" is the right place to put developers in the analogy. Certainly they are present and instrumental in the "birth" of software. But I wouldn't say a developer's role in creation is their primary function on a software project. Reaching again into my own experiences, I spend far more time fixing and enhancing existing software than creating brand new software.
Software just sort of happens under the right circumstances, if steps aren't taken to prevent it. We developers may help to bring about those circumstances sometimes, but mostly we seem to work to bring software to maturity, keep it going for a few years, and then ease it into end of life. I'm not sure what that makes us.
A different and brilliant perception!
SvarSletRather than "creator", maybe we can call developers their intellectual "parents"? They should know the most about the applications, obviously, but perhaps not all their extra-curricular activities?
SvarSletI feel that extends the metaphor for their involvement in treatment as well. ;)
Hi James, Interesting analogy, keep updating. These kind of analogy are rare to find on Internet, yaap you need to dive deep into the subject to get through it.
SvarSlet