Daniel Read has a very thought provoking post on whether software needs an Apgar score.
First, I encourage you to read both the original New Yorker article and Daniel's post.
What is the Apgar score? If you don't know, you didn't read the article, so go back and read it. Okay, okay :) The Apgar score is a method used to determine the health of a baby at childbirth. The baby is scored between 0–2 on five factors: heart rate, breathing, muscle tone, skin irritability and skin colour, giving a total score between 0–10. The score is measured once at 1 minute after birth and again at 5 minutes after birth. A score of 7 or more is a healthy baby. Less than seven does not necessarily indicate an unhealthy baby, but doctors will look at the baby to be sure. Before the score was devised, determining the baby's state was a complex mass of subjective measures which often meant that the baby was not given treatment when required because some factor was overlooked.
The key idea behind the Apgar score is that it is simple. It is simple to calculate. It is simple in that it condenses a number of subjective factors into one number. It is simple in that an instant decision can be made as to whether the baby is healthy. The final Apgar score does not take into account the myriad complexities, but it is intentionally kept simple so that it can be used as a quick, shorthand method of assessing the baby's health. That's what it is—a quick, shorthand assesment.
Daniel asks a question—Do we need an Apgar score for software development? Something that can serve as a quick, shorthand assesment of the project's health. Current methods of determining a project's health are a complex mass of subjectivity. Maintainability? Security? Relaiability? Code coverage? Usability? Requirement satisfaction? Customer satisfaction? There is no effective means of quickly measuring the project quality in a way that would give a rough idea as to the quality of the software. An Apgar score could help a lot here. It need not be exact. It just needs to be somewhere in the ballpark so that a decision can be made as to whether the project is healthy or we need to investigate more.
I think this is an interesting idea. It may not be practical as yet for software, but is nevertheless thought provoking. Check out some of the comments on Daniel's post as well.
This post is a part of the selected archive.