I got an interesting and slightly distressing e-mail the other day from a longtime friend of mine. We'll call him Ben. Ben is a programming team leader and wrote to me asking, "How do I get my programmers to take pride in their code? I've lent out my copy of Code Complete (Steve McConnell's superb book on software construction techniques), I've preached about how consistent style makes maintenance and upgrading easier, and I've provided countless examples, all to no avail. Some of my team's code makes my eyes bleed! What can I do to reach these programmers?" I paraphrased slightly, but the question is worded almost exactly as Ben wrote it.

Reprogramming Your Programmers

Though a programmer from any background can, and often does, write the kind of code that makes Ben's eyes bleed, longtime RPG coders are especially at risk for exhibiting the kind of traits and habits that lead to poor coding style. Many of these behaviors are partly at the root of Ben's problem. Ben needs to start by "reprogramming" these traits in his programmers.

In an effort to identify the type of coder we're looking to reprogram, let's consider a few traits and habits. The programmers in your organization whom you need to willingly, and frequently, drink from your "code complete" Kool-Aid are those who

• are lax about coding consistency (e.g., the use of seemingly random variable names, ignoring or not properly indenting code, random use of upper and lower case)
• don't comment their code well
• pay little or no regard to shop standards, conventions, and patterns
• write dense, compact code with very little white space
• use the project deadline as an excuse for poor code (the old axiom "If you don't have time to do it right, how will you find time to do it again?" applies in spades here!)
• justify first-pass crummy code by saying they'll rewrite it better later — that never happens

For many longtime RPG programmers, the care and attention to detail required to write really great code was never burned into their coding discipline. Back in the old days, everything was upper case! Who cared about case? White space? Ha! RPG's pathological insistence on columns dictated most white space (we did manage to put the occasional asterisk in column 7, but that was usually more for commenting a following line than for white space). Even project deadlines were different in the old days. Before the days of relentless cost-cutting, outsourcing, mergers, and acquisitions (all of which threaten to decimate your programming staff), deadlines were more of a "we'll finish it when we finish it" thing than they were real deadlines. It's easy to see why a coder with a deep and rich RPG background might tend to eschew, or least not be totally aware of, the value of modern productive and useful software development techniques.

It's Ben's job to figure out how to make these coders not only understand the conventions, techniques, and standards he requires but also to appreciate them and believe in them. Applying shop standards and conventions isn't something that a coder should see as a burden. Rather, standards should be embraced and pursued as being as fundamental to a successful project as making the program compile.

The Recipe for Code Complete Kool-Aid

What should Ben do? To help his programmers learn better coding habits, Ben should

• Publish conventions and standards. Your coders can adhere only to what they can see and understand. You need to have formally published, on the web or intranet where all can see, what your shop's coding conventions, standards, and patterns (and therefore your expectations) are. Though this can't be an absolute democratic process, consider publishing these standards with bloglike feedback possibilities. Some of the renegades may actually have a good idea or two to improve the standards.
• Convey the importance of building enterprise assets (i.e., convey the "why" as well as the "what" and "how"). As you explain your conventions and standards, make sure your coders see these principles in the context of the larger picture. It's important that they see how their projects fit into the grand scheme of things. They need to know that their code is doing critical tasks and that many people depend on it working.
• Perform regular peer code reviews. Get together once a week for a short time and have programmers share and discuss recent code they've written. This not only gently starts to build a general sense of camaraderie, but it also raises programmers' awareness about their code. There's something about knowing you need to explain spaghetti code that makes it less pastalike! Also consider having little coding challenges at these meetings. It's amazing how much discussion can be driven by a good challenge. (Try Google "fizz buzz" for an example challenge.)
• Reward great code. Collect the code shared at your peer review meetings and periodically reward the best authors. For really great code, consider a Spaghetti-in-its-place award — a gift certificate for two to a nice Italian restaurant (the pasta is on your plate, not in your code!). Make it fun and highly desirable to have joined the Spaghetti-in-its-place club.
• Designate mentors. As you work actively with your coding team to raise the bar on their code, you'll notice that some coders start to gravitate quickly to your conventions and processes. Pair these early achievers with those on the team who are slower to embrace the principles.
• Make sure your coders have prideworthy tools. If you want your coders to take pride in their work, take pride in them. Make sure a well-stocked library of coding books is available. If you can swing it with management, get everyone two large monitors. Having two monitors dramatically increases a coder's productivity. Though you probably can't convince management to get each team member a Herman Miller Aeron office chair, make sure your programmers' workspace is as good as you can afford.
• Lead by example. As a team leader, your code needs to be stellar! It also needs to be shared frequently (without acting as though you've been recognized by Kozmic Muffin as writing the Best Code Ever).
• Critique gracefully. When a programmer submits less-than-great code, discuss it critically and in a timely fashion. By all means, be sure to keep the conversation focused on the programmer's code, not the programmer. After the conversation, you want the coder thinking about her code, not about what a jerk you were in dogmatically demanding that she "follow the rules."
• Start an internal blog to share ideas and thoughts. You don't want to have too many meetings, but you need to keep everyone in the loop as frequently as possible. With a development team blog, you can keep coders in the loop and collect important feedback. This collaborative online presence is also a great place to share recent online articles and other related URLs.
• Adopt a formal methodology and application development management process. Your team is going to be only as good as they see you and your processes being. Good processes keep the team focused and clearly aware of your schedules and priorities. If you're not the reason the team is successful, then you are the reason they are failing! (See "Score with Agile Software Development," July 2007, article ID 20955 at SystemiNetwork.com for more formal methodologies and processes.)

Keep me posted, Ben!

Roger Pence is education director for ASNA, an application development tools company, where he focuses on helping customers build browser- and Internet-based line-of-business System i applications. Roger has spent many years writing and speaking about the System i.