When I read the article [1] Daniel referred to in his Apgar score post [2], I thought I knew exactly what the relevance of the article to software engineering. It turned out I was focusing on a completely different passage than Daniel was. Here's what I focused on:

...Babies who were born malformed or too small or just blue and not breathing well were listed as stillborn, placed out of sight, and left to die. They were believed to be too sick to live. Apgar believed otherwise...

[Thus Dr. Apgar developed her scoring system to counter this problem.]

...even if only because doctors are competitive, it drove them to want to produce better scores—and therefore better outcomes—for the newborns they delivered.

Around the world, virtually every child born in a hospital had an Apgar score recorded at one minute after birth and at five minutes after birth. It quickly became clear that a baby with a terrible Apgar score at one minute could often be resuscitated—with measures like oxygen and warming—to an excellent score at five minutes.

This got me thinking to a conversation a friend of mine and I have been carrying on over a period of some years now. We started out by observing that some managers did not seem to believe there were any substantive qualitative difference between programmers, and moreover, those few that did usually were incapable of accurately distinguishing a good programmer from a bad one.

Moreover, poor programmers often do not see themselves as such. They get assigned requirements, they write a crappy, unscalable solution for those requirements, and they still go home confident that they've done a good job.

Similarly, obstetricians saw no difference in outcomes between a stillbirth and a healthy child: they got paid either way. Surely, if they knew that they had let a baby that could have been saved die, they would feel badly about it, but if they had been trained that a child that was not breathing immediately after birth could not be resuscitated...

For software developers, frequently it's even worse than that. If a child is born to a poor obstetrician, after it goes home it's generally safe from further malpractice. Once the software with the low Apgar rating hits the streets, it generally will get maintained by the same developer - if for no other reason than the author is the only one who can read the code.

What happens next is what my friend and I found really disturbing: The unskilled developer is seen as a big hero because whenever something goes wrong, this fella comes running in at whatever hour of the day and, within a couple hours, has the program up & running again. Hurray! The hero saves the day! Whereas when a problem develops in well-written code, it often takes a long time to solve. From the standpoint of management, the bad programmer is the genius because he solves lots of problems quickly and the good programmer is useless because it takes a longer for him to solve the problem.

Managers and Executives only know about problems that actually happen. Problems don't happen nearly so often in good code and when they do, the problems usually run deep. Further, non-programmers usually are not equipped to understand that the problem that afflicted the well-written application was far more substantive than the dozens of tiny problems that beset the poorly-written code.

Software quality metrics rarely work. I don't think I could say it any more eloquently than Brad did when he said "For any metric you can design, I can write crappy software that meets the metric perfectly."

Moreover, I know a lot of superbly written code that never got ran, and I know some crappy code that runs every day and enjoys widespread acclaim amongst its users. I know this with some certainty because I've written both. Moreover, I think that most people, myself included privately define "high quality" software as software that looks like software that they wrote.

You can go on about one pet peeve or another, but just as Brad can write crappy code that meets the definition of quality code by the software metrics, I can write great code that breaks the metrics. At least if you let me define "great" as highly reliable, scalable, and exceeding customer expectations.

When I was younger, I observed that whenever I looked at code that I wrote a couple years ago, I was always appalled that I could ever have written anything so crappy and thought it was good. I think most good developers have that same feeling. Now that I've, uh, "matured" a bit, I've utterly changed what I view as "good" and "bad" code. In my new way of thinking, "good" code gets run. "Bad" code doesn't. It's that simple.

For example, I wrote a program in a great hurry many years ago that would fail any reasonable programmer's definition of good code. That code got run for years and years without anybody doing maintenance on it. It wasn't extensible, but then nobody wanted to extend it (or at least not badly enough to want to try to penetrate how it worked). It wasn't scalable, but the dataset size remained constant. So, how can you say that this was bad code? It delivered more customer value than any product I have written before or since!

Still, this is an unusual case and its "good code" standing probably owes more to luck than skill. In general, I think it's probably safe to say that poor quality code tends to get maintenanced-out of the product. If it gets run that is.

My notion, which I'll put to the gallery for comment and ridicule, is that it might be possible to write a tool that looks at the Source Code Control database and ferrets out who writes the code that hits and sticks, versus who writes code that gets patch after patch applied to it.

If you had such a tool, I believe it would have the same social impact as the Apgar score: engineers who thought they were good coders might finally start to realize that they are not, and be motivated to learn new techniques that might improve their score.