Merely trying to read the code may be instructive. Can you figure out what it does in the first place?
When Microsoft announces that it will stop writing code for a month, devoting its attention to a bottom-up review of what it ships now, I hope that every organization is inspired to similar measures.
Reading your current production code and asking, "Why does it do that?" is just the initial goal that may expose a greater challenge. Merely trying to read the code may be instructive. Can you figure out what it does in the first place?
As Kernighan and Plauger observed in their 1978 book, "The Elements of Programming Style," "If youre as clever as you can be when you write it, how will you ever debug it?" Sitting down for a spell of code reading may elicit uncomfortable discoveries as to how clever you have been in the pastand how much more clever you may need to become.
Java guru Ian McFarland, president of Neo Ventures, in Santa Monica, Calif., offers a readability criterion that many coders share: "If a method is too big to fit on one page of screen, its too long. If you dont read it and go, Yeah, that makes sense, its too complex. Simplify."
I feel this way, not just about methods in code but about entire systems. If you cant describe the overall function of the system on the proverbial 3-by-5-inch index card, how can you begin the process of top-down decomposition that leads to understandable specifications and maintainable implementations?
You can build something that works, even if it doesnt make sense, but it will take longer to build, and it may be impossible to fix. As Microsofts Anders Hejlsberg said at the launch of Visual Studio .Net, to appreciative coder laughter, "It used to be that all we could do was list thousands of Windows entry points in alphabetical order. Now, theres a name space: When you want to do something, you know where to look." (Ill add that you may need to read other things than code: Do your paper forms capture data correctly?)
Take the time to look around, as well as inside your systems, and think about what you want them to do.
Tell me what your reading uncovers at firstname.lastname@example.org.
Peter Coffee is Director of Platform Research at salesforce.com, where he serves as a liaison with the developer community to define the opportunity and clarify developers' technical requirements on the company's evolving Apex Platform. Peter previously spent 18 years with eWEEK (formerly PC Week), the national news magazine of enterprise technology practice, where he reviewed software development tools and methods and wrote regular columns on emerging technologies and professional community issues.Before he began writing full-time in 1989, Peter spent eleven years in technical and management positions at Exxon and The Aerospace Corporation, including management of the latter company's first desktop computing planning team and applied research in applications of artificial intelligence techniques. He holds an engineering degree from MIT and an MBA from Pepperdine University, he has held teaching appointments in computer science, business analytics and information systems management at Pepperdine, UCLA, and Chapman College.