Summary
In most commercial projects, "code quality" doesn't matter because code is seldom the end-product of the development effort - it's the binary that we ultimately ship. Total product quality matters, and process and skill weigh more than code quality in determining overall product quality.

Advertisement

In a recent blog post, Bill Venners ponders if you can "write quality code quickly."
Some of the ensuing discussion betrays an unfortunate misunderstanding about code
quality. To illustrate, I have almost never met a developer working on real-life,
production software in a business environment who was completely satisfied with the
code he was working on.

If anything, I almost discern an inverse relationship between how satisfactory a
piece of code is to the developers working on that code, and the amount of money that code makes for those developers' employers.

The other day, for instance, I was
having brunch with a friend who toils for a living on the crucial server component of one of the world's largest and most profitable database companies. He lamented about
the ugly naming conventions used in that huge code base, and how that makes it hard
for developers to work on the code. Yet, that same codebase is good enough to
generate several billion dollars in revenue for that company.

I think much of the eternal developer lament about code quality has to do with the
strange and highly unusual job of the software developer. If you're a musician, all
day long you practice and work on the actual output of your job, the music. You can
work to shape every note and phrase to your liking, and, with luck, those practiced
nuances will come off the same way during a performance or recording. If you are a
carpenter, you spend your day working on the actual chair or cabinet that is the
final output of your work. As a physician, your work is performed directly on the
main object of your profession, the patient.

As a developer, almost nothing you work on ever leaves your development environment
or the close confines of your development team: What you ship is the binary, not the
source. Unless your product is, or includes, the source code, almost no one outside
your team ever sees - or cares about - the source code you spend the precious hours
of each day writing.

It follows that few people outside your close team members ever care about the
quality of that source code. And most compilers don't care about source code quality, either - how you name your variables, how long and clean your methods are, the clarity of your object model, or even the algorithms you use, are of little interest to the compiler that can happily create an equivalent binary from ugly or pretty code.

Of course, we as developers must care about code quality, since we spend most of our
waking hours working on code. And, as every good craftsman, we strive for quality. A physician would want to practice high quality medicine, or any carpenter worth his
salt would want to produce a quality staircase or chest. As developers, we also like
to produce and maintain a high quality code base.

The trouble is, a quality code base often doesn't matter in terms of our final
output, because the compiler is there to mediate - it obliterates ugliness as much as it wipes away beauty. And users care only about that final, binary output. For instance, as you read these words, you care little about the quality of the code that the Java compiler translated to the binary version of this JSP page.

When we spend time to make our code high quality, we justify that effort by saying that the work would provide some business benefit down the road. The trouble is,
code quality, by itself, seldom results in any measurable business return on
investment, as many commentators on Artima have observed. The database company my
friend works for, for instance, may have "ugly" or hard-to-read code, but that code works just as well. Instead, that company is better off focusing on overall product quality than on code quality.

And total product quality, as Edwards Deming noted, is not the result of merely improving the quality of a single activity, but is rather the outcome of a set of processes focusing on the quality of the total output. In this case, that total output is the binary we ship. Developer testing, agile development methods, quality assurance, continuous integration - these are all processes that facilitate a high quality of total output. Code quality is but a small part of that effort. An organization can
get a better return on investment from focusing on the processes that lead to a
quality product, than by placing a great deal of emphasis on code quality.

Managers, intuitively or by learning, seem to understand that - to the chagrin of
developers, who must work on the level of the code day after day. That's sad news,
because it means that we, developers, are doomed to eternal complaint and frustration about code quality.

Talk Back!

Have an opinion?
Readers have already posted
46
comments
about this weblog entry. Why not
add yours?

RSS Feed

If you'd like to be notified whenever Frank Sommers adds a new entry to his weblog, subscribe to his RSS feed.

About the Blogger

Frank Sommers is a Senior Editor with Artima Developer. Prior to joining Artima, Frank wrote the Jiniology and Web services columns for JavaWorld. Frank also serves as chief editor of the Web zine ClusterComputing.org, the IEEE Technical Committee on Scalable Computing's newsletter. Prior to that, he edited the Newsletter of the IEEE Task Force on Cluster Computing. Frank is also founder and president of Autospaces, a company dedicated to bringing service-oriented computing to the automotive software market.

Prior to Autospaces, Frank was vice president of technology and chief software architect at a Los Angeles system integration firm. In that capacity, he designed and developed that company's two main products: A financial underwriting system, and an insurance claims management expert system. Before assuming that position, he was a research fellow at the Center for Multiethnic and Transnational Studies at the University of Southern California, where he participated in a geographic information systems (GIS) project mapping the ethnic populations of the world and the diverse demography of southern California. Frank's interests include parallel and distributed computing, data management, programming languages, cluster and grid computing, and the theoretic foundations of computation. He is a member of the ACM and IEEE, and the American Musicological Society.