CodeGuru content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
I wrote my first lines of code in 1978. I was 12 years old and the computer was a TRS 80 (what we now refer to as a Trash 80). Consumer computers didn’t get interesting for me again until 1987—Quattro Pro 1.0, 3D graphics, a 386SX processor, and I was hooked. Teenage girls, a driver’s license, and a stint in the Army happened in the intervening years.
Since 1987, I’ve read and written a lot of code in a lot of languages and dialects. One thing I’ve noticed is that most code looks like a Rube Goldberg invention—especially my code. Although conscientious programmers care about what their code looks like, they generally aren’t permitted the time to make code beautiful and users of the end product don’t care what the code underneath looks like anyway. In this article, I will tell you why both users and programmers should care more about the elegance of code.
First, I suppose I should explain who Rube Goldberg is. He was a cartoonist who, until his death in 1970, incorporated his engineering background into his cartoons. The former president of the American National Cartoonists Society is famous for drawing comical inventions that involved laboriously contrived and complicated machines to perform simple operations (see his “How to Keep the Boss from Knowing You Are Late for Work” for an example). The cartoonist’s name is now synonymous with the notion of these comical inventions.
The Paradox of the Creative Software Mind
Programmers are equal parts artist and scientist. We, in fact, are left-brained artists. Our mind’s eye sees the programs we invent in terms of bits, bytes, pseudo-words, phrases, and constructs. What we see is as much art as it is logical calculus. Unfortunately, software is an invention of the mind, an invention that seldom if ever goes through the necessary refining process that most art needs. Thus, programmers labor away hoping that they will ultimately get to polish their work—the code—before anyone ever sees it in operation. However, they know that what they write the first time may go out the door, and like the teenager off to college, seldom return.
My Walter Mitty fantasy is one day to write code so beautiful that were it to be laid out as a single mosaic of characters, it would look like a pointalistic rendering worthy of Seurat. Although programmers like me care that much about code’s appearance, users don’t. Users care only about the packaged results. The end product is mostly a tool and users just want the tool’s capability. Only the artists care about code-as-art.
Users should care, though. They should care because beautiful code will ultimately run more reliably—reliability is a by-product of elegant code, which is cheaper to produce, cheaper to own, and cheaper to grow. Programmers and computer scientists know this, but the rest of the world doesn’t care, so we aren’t really permitted the time to impart our care into the end result.
Uncomplicating Code
The challenge for programmers then is creating beautiful, uncomplicated code in a simple and inexpensive way. When time is a luxury, how do we care on behalf of those who should care but don’t? The answer is using code that is already beautiful.
We have to use code that has been honed to a fine edge. Existing code often has been refined to some extent, hence its survival. Generally, it can be cheaper to use, and you can refine it as you are retrofitting it for your specific needs. Three other sources of such code are available:
- Design patterns represent pre-existing solutions that have been carefully coded and improved over time.
- Refactoring represents rules for factoring code to make it simpler.
- A good solid framework is generally representative of code written by expert programmers whose product actually is the code. Framework code is more likely to be beautiful code.
Unfortunately, many programmers suffer from the not invented here syndrome, pumping out one Rube Goldberg device after another. How do I know? Because I like the inventing and creating process too. Like all aspiring artists, I know many beautiful works of art already exist but I keep inventing anyway.
Good Products for Users, Beautiful Code for Programmers
There is a chain of mega-grocery stores in the Midwest called Meijer (formerly Meijer Thrifty Acres). Every once in a while, the good people at Meijer move everything around and customers can end up wandering around for hours looking for an everyday item. Call me a conspiracy theorist, but I think Meijer does this to force browsing and ultimately the spontaneous purchase of items—a major pain in the butt.
Sometimes I think users view programmers the way I view Meijer. They believe that programmers make the digital world unnecessarily complex. The truth is we aren’t trying to make simple things complex. I argue that many programmers are so busy inventing—and really digging the invention process—that they aren’t even thinking of real users.
The way to bridge the gap between the user’s need for a good product and the programmer’s desire for beautiful code in the short time they are permitted is leveraging patterns, refactorings, great frameworks, and existing code. That way, we can hone our inventions with the time we used to spend writing them from scratch.
About the Author
Paul Kimmel is the “VB Today” columnist for codeguru.com and developer.com and has written several books on object-oriented programming, including the recently released Visual Basic .NET Power Coding from Addison-Wesley. He is a software architect and recently has way to much free time on his hands.
If you want to vent, learn about great new technologies, eat free pizza, and live in the greater Lansing, Michigan area, consider dropping by the Greater Lansing .NET Users Group (www.glugnet.org), or if you live a long way away, really impress us by flying in.
Copyright © 2007 by Paul T. Kimmel. All Rights Reserved.
