Employeers, recruiters, contractors, and academics need to understand . . .

Where Did All the Good Programmers Go?
© Conrad Weisert, Information Disciplines, Inc., Chicago
6 May, 2012

NOTE: This document may be circulated or quoted from freely, as long as the copyright credit is included.

Background: Popular opinion

In several recent professional meetings the question was posed:

"Does today's software exhibit higher quality than software developed two or three decades ago?"

Participants agreed resoundingly that the answer is no! In view of the many breakthroughs in software development methodology and the constant improvements in programming languages and other tools, this assessment is surprising, disappointing, and puzzling. Observers complained that some modern software is of far worse quality than typical software of past generations.

That assessment applies both to commercial software products and to applications developed in-house by user organzations.

An obvious truth for most of us is that:

— Good programmers usually develop good software.  
— Bad programmers always develop bad software.

That may disappoint managers of the a-programmer-is-a-programmer school, but we're well acquainted with the applications their staffs produce.

What is a good program?

We've noted that the term quality has gotten debased. In many circles1 it has come to mean little more than absence of "defects" or program bugs. Surprisingly few programming managers can explain what a good program is. As consequences:

The naïve 1960's cliché:

"Any program that works is better than
any program that doesn't work.
"

has returned and is thriving in both software development organizations and universities.

So, what's a good programmer

We noted earlier that a good programmer usually writes good programs. A programmer who turns out unmaintainable, inefficient, bug-ridden software is not a good programmer. Neither is a programmer who violates an organization's standards and methodology.

Furthermore, a good programmer is usually productive. It takes him or her less time and other resources to produce a high-quality program component than for a mediocre programmer to produce a poor-quality program component.

Finally, a good programmer exercises sound judgment, appropriate to his or her level of experience.

Building a staff

So, why doesn't everyone hire only good programmers? Why are there so many mediocre and really bad programmers? Among the dozens of factors influencing that phenomenon these three may dominate:

As we've been pointing out for some time all of those are easily overcome. Interviewing must be done by a competent professional. The candidate must provide samples of his or her work, and the organization must realistically evaluate the quality of those samples. Graduates of Computer Science programs known to emphasize quality should be regarded favorably.

In-house development of inexperienced staff should also emphasize quality, and must be presented by instructors or contract education firms who themselves understand the issues.


1—Including professional organizations whose names include "quality" or even "quality assurance"!

Last modified 6 May 2012

Return to IDI Home Page
Return to Management articles