"Clean Code": Agile Handbook or Engineering Attack?

A year ago I mentioned the comments quoted in Slashdot by Robert Dewar, a professor specializing in software engineering (The ACM Lost Its Way", Lone Coder). Mr. Dewar was concerned about the lack of problem solving and computer theory taught in schools, especially as it relates to Java with it's "down load a class" theory of programming. I had mentioned this to a developer who was complaining that many Java developers simply didn't know how to code. "Java: it's the new Basic", I said. "That's it!" he replied with righteous indignation.

I was thinking of this as I was reading "Clean Code: A Handbook of Agile Software Craftsmanship", written by Robert C. Martin, a key person in the development of agile programming. Agile development can be looked at as a natural outgrowth of the Java "download a class" methodology: to approach a project by focusing on the short-term: start programming immediately, set small achievable goals, hold frequent assessments as the project progresses and to have no responsibility for the overall project (each developer is responsible for their own work). In agile development, reliability and scalability are issues to be dealt with later, small subtasks to be periodically examined.

Right from the beginning of the book, I was left wondering about the research done for this book. When talking about functions, the book says "In the early days of programming we composed our systems of routines and subroutines. In the era of Fortran and PL/1 we composed our systems of programs, subprograms and functions. Nowadays only the function survives from those early days." (pg. 31) The author, of course, is talking about the keyword "function" since routines and subroutines still conceptually exist in many languages in common use today.

In another peculiar statement he says about the "goto" statement that "goto only makes sense in large functions and should be avoided" (pg. 49). I had never heard this view before and Martin makes no effort to justify his opinion. The "goto" statement is commonly used for dealing with the limitations of flow-control structures such as exiting multi-nested compound statements or handling exceptional events such as interrupted system calls in Linux. It has nothing to do with large functions.

The book is peppered with cute but meaningless phrases to impress your coding buddies at work. Once such statement is "The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that." Functions conceptually break a program down into smaller components, but in reality this reduces performance and can make reading the program more difficult. They are times when the number and size of functions are constrained by execution time or real-time time response limitations. The book never looks beyond functions and objects for methods of dividing and organizing programs, which shows how the agile programmer "majors in the minors".

When talking about function parameters, the author argues that the assignment a = f() and a one parameter reference f(&a) are the same...which they are not. Some languages, like Ada and my Business Shell, have types that can be parameters but cannot be assigned in an assignment statement.

"Comments are always failures. We must have them because we cannot always figure out how to express ourselves without them but their use is not a cause for celebration." (pg. 54) This overlooks the fact that code is, by its nature, a model of reality that must be tied into the real world. It also ignores the idea of attaching comments onto the end of lines so that it belongs to a context. Out-of-date comments are described as a big problem--though in 20 years of programming, I've never seen a case of it.

Likewise, he doesn't address marking temporary debugging statements with comments during development so they can be quickly searched for and removed when the program is working. Or marking distant braces for large blocks (arguing that IDE's exist and that programs would never be viewed in any other medium.) Nor does he address the problem of English comments in multi-ethnic cities where teams may have several speakers for whom English is not their first language. This is a big problem in Toronto, Ontario or London, England or in any kind of open source development.

When objects are involved, the usual solution is to use more objects. Objects, in some ways, have become the "goto" statement of modern languages, used to solve any problem if you can nest enough of them. In one example, the book says that switch statements are bad and should be wrapped in a factory class (pp. 38,39) or using multiple container objects to fake Aspect Orient Programming in a language that doesn't support it or using objects to get around dependency injection which is a problem with the Java language itself (Chapter 11).

The book is constructed much like an agile software project: good ideas, unrelated, thrown together with no vision of the overall destination. There's no in depth evaluation of anything, no search for trends, strategies or alternatives. It should be taken as a collection of rules of thumb. It many cases the book touches on issues of human physiology, psychology and how people interact with machines but it doesn't go into a discussion of these underlying issues In general, the book lacked any kind of industry experience or knowledge of the history of programming practices, more concerned with keystrokes than sound design.

The matter-of-fact way the book assumes it's right about everything made me wonder if clean code should be less about finding the best way to lay out ones programming and more about different, competing and incompatible theories, each with it's own set of tools, that make sense in its context. For example, in one comment on style made no sense with one theory of clean code but with another theory, with different tools, that same commenting style may be a part of a sensible approach. Because the book focused on minor issues, it missed the bigger picture of what makes different approaches work.

The real benefit of agile programming is the making others repeat the sin of programming: to love your own design. In writing, there is an expression: "kill your darlings". Authors know that a beautiful paragraph that doesn't fit into a story must be deleted, no matter how how much work went into making it. The story is all that matters. But agile programming focuses on the short-term. A developer can work for months in order to deliver a project that end-user will reject with "that's not what I wanted" in two minutes. With agile programming, since managers are involved in and have an emotional attachment to the project, it's more likely they'll sign off on a clever but useless design. It's not because the end-user gets what they want but they want what they get. The big picture of the project is still lost.

If you're looking for a book that explains how to use language features correctly, I'd recommend "Effective Java" by Joshua Bloch. Written by a Sun Java developer, it goes into why Java features are there and how they were meant to be used. It has also been updated for Java 1.6. As for "Clean Code", it's worth a read but it is definitely not one to buy and put on your bookshelf. It's more a commentary of both the design of Java and the mindset of Agile Programming where learning from the past (or present) is a considered a waste of time. It would pay Martin to remember that those who don't learn from the past are doomed to repeat it.

February 18, 2009