"Clean Code" isn't necessary today, because it succeeded

A recent rant - no, a complaint - about Robert Martin's "Clean Code" raises interesting points.

Yet while reading the complaint, I got the feeling that the author (of the complaint) didn't understand the situation at the time, and the purpose of "Clean Code".

"Clean Code" was written in 2008. Prior to that, programming in Windows was difficult. The tools were inconsistent and difficult to use. Not all tools worked with other tools. Getting one's development environment working was a challenge, as was keeping it working. Programmers had to worry about lots of things, and the quality of the code was low on the list.

Programmers in companies (that is, most programmers) had to worry about schedules and due dates. Here, the priorities were clear: shipping a poorly-built product on time was better than shipping a "clean code" product late.

Very few programmers worried about the quality of their code. Very few programmers talked about "clean code". Robert Martin was one of the few who did.

Converting poorly-designed code into "clean code" was not easy. We did not even have a standard for clean code -- everyone had their own ideas. Robert Martin gave us some standards for clean code. He also made the argument that making code clean from the start was better than writing poor code and later making it clean. The effort to make code clean (refactoring large functions into smaller functions, renaming variables and functions) often had to be done manually, and required a fair amount of effort.

Over time, programming tools improved. Windows improved. Testing tools improved. Version control improved. As tools got better, programmers could spend less time worrying about them and more time worrying about the quality of code. Also, the argument of "clean code" was beginning to make sense to managers. Studies were showing that clean code was less expensive overall, slower to write but faster to debug and faster to change, easier for new team members to understand, and less prone to defects when changes were made. Those studies made the argument for clean code to managers in terms of money, time, and risk (three of the four dimensions that managers understand).

I think we can say that "Clean Code" marks the time that PC programmers (programmers of Windows applications) stopped worrying about tools and technology and were able to worry about the quality of their code. Or at least a significant number of programmers.

"Clean Code" is not suited to today's development. It relies on an early version of Java. It is heavily object-oriented. It recommends some extreme code techniques ("functions of no more than two or three lines"). Yet it contains truths ("a function should have no side effects").

But the suitability of "Clean Code" is not my point. My point is that "Clean Code" marked a turning point in IT: a point in time when programmers had enough free time to think about the quality of code, and they could be persuaded to do so (as could managers).

Since that time, many of the ideas of "Clean Code" have become accepted as standard practices. The author of the complaint (the only name I found was the nom-de-plume "qntm") notes "This is all good advice, if a little tepid and entry-level".

Perhaps we can look back with some sense of satisfaction that "Clean Code" is no longer necessary. Robert Martin's plea for programmers to think about quality was a success -- programmers now think about quality, so much so that programmers with less than a decade of experience might think that it has always been done this way.

Three additional thoughts --

This complaint marks another point of progress: when programmers accept as a given that code quality is important and deserving of attention. The actual point may have occurred earlier, but this is documented evidence of the attitude about code quality.

The rise of Agile methods may have helped the focus on quality to gain acceptance. (Or perhaps the focus on quality helped Agile gain acceptance. Or maybe they form a self-reinforcing cycle.)

The Linux folks can (rightfully) point to Kernighan and Plaugher's "The Elements of Programming Style" from 1974, some thirty-plus years ahead of Martin's "Clean Code". Written from experience on Unix systems, it covers many of the same ideas. Its early arrival is not surprising; Unix had a stable set of tools that worked well together, and Unix was often used in research and academic settings which have different attitudes towards due dates and quality of work.