Simplicity and Getting It

by Eric M. Burke

The art of writing simple, concise code has been on my mind lately. Actually, I'm more concerned with overly complex code. When I see huge blocks of overly complex code with lots of duplication, horrible variable names, and obvious bugs, I do everything in my power to fix the problems. I just cannot stand to leave garbage code in place if I can help it. Bad code bothers me.


What troubles me is the observation that we have legions of programmers who don't seem to "get it" when it comes to writing maintainable code. They are happy to produce reams of code that seems to solve the immediate problem at hand, and are perfectly content to move on to the next problem, leaving all of this horrible code behind.


The million dollar question is...how can we train programmers to be passionate about crafting quality code?


Sometimes the problem comes down to experience, which is perfectly understandable. As a programmer matures and gains more experience, I would expect him to write better code. The best programmers solve problems with fewer lines of code than beginners. Over time, most people get better.


The true challenge occurs when you have people who have been programming for years but don't seem to have an appreciation for simplicity. They seem to produce "Rube Goldberg" code for any given problem, always finding new ways to bypass standard frameworks and reusable solutions in favor of complex, convoluted code that is unique to each situation.


So what can be done?


First, I recommend that all programmers read "The Pragmatic Programmer: from journeyman to master", by Andrew Hunt and David Thomas. This is a GREAT book, and should be required reading for all programmers.


Second, I think that projects need some sort of technical oversight. In the traditional model, you would need a strong technical leader who stays abreast of changes in the code and constantly suggests better solutions. Code reviews are also invaluable, and should not be deferred until the end of a project.


In an XP environment, pair programming helps. Whenever I pair program I find that two people almost always come up with simpler solutions to any given problem. Just the fact that you are sitting down and explaining your code as you go forces you to slow down and think about problems more carefully. Having someone look over your shoulder also makes you feel guilty when you write really bad code...


I have definitely seen scenarios where lack of communication results in hugely complex, buggy code. The problem is that programmers who write bad code probably don't have any sense for how important ideas like refactoring are. Unless you expose them to these ideas through code reviews, pair programming, or other forms of team communication, they may never improve.


Writing great code is a mysterious blend of technical skill, experience, and art. I am not convinced that all people can be taught to be passionate about writing great code. I am, however, convinced that the best strategy for success is good communication among team members and an environment where people get to see and review each other's code on a continual basis.