More Lazy Programming

After yesterday's post, I did a quick survey today of prior references to "lazy programming" and found a few kindred sites and posts in the Wiki web.

Brad Appleton has a terrific Wiki entry which begins with a quotation of Larry Wall (co-author of Programming Perl): "We will encourage you to develop the three great virtues of a programmer: laziness, impatience, and hubris." Brad's Wiki entry is entitled, "Laziness Impatience Hubris" and the laziness portion is summarised by the line, "You're not just thinking about how to be lazy right now, but about how to continue being lazy from now on through the foreseeable future (such advance laziness requires thinking ahead ;-)."

There is another Wiki entry by Peter Sumskas specifically entitled "Lazy Programmer" that paraphrases the Einstein Principle as, "Do as little work as possible to get the task completed, but no less." Unfortunately this approach only meets First Lazy Form and unlike Brad's entry above misses the real advantages of Lazy Programming.

On the flipside, there is also a "Lazy Bastard" page with Wayne Conrad's minimalist, "LeoScott insists that the best programmers are lazy programmers." Without the benefit of any rationale (as Brad Appleton provided), it drew this strong reaction from David Thomas: "Lazy programmers are bad programmers. Lazy programmers cut corners, don't bother to keep up in their field, and duck responsibility. However, efficient programmers--people on top of their craft, their project, and their environment--may appear to be kicking back more than their less efficient brethren."

Yes, those dudes are bad programmers, but it misses the point. A point which Wayne unfortunately did not mention.

Do not write David off yet. Dig deeper and he provides terrific insight in his "Pragmatic Programmer" page. He co-authored a book of the same name. The basic principle is that, "Pragmatic Programmers are not wedded to a particular methodology, language, operating system, notation, whatever. Instead, they use their experience, combined with research, to choose the most appropriate combinations of tools for the job at hand." Well said. You can only improve that by adding Long-term Laziness as a guideline by which they judge tools for the job at hand.

Never believe that "experience, combined with research," results in the best solution. Always question. A programmer should back up intuition with provable metrics. The emphasis should be on research. Long-term Laziness can and should involve solid metrics, whether lines of code, speed tests to defend choices of implementation, bug tracking and bug repair logs, stress tests, user feedback, usability surveys, and peer review, all weighted according to the requirements of the "job at hand." I expect David does not ignore measurement of success in the book, but I would hate people to read his Pragmatic Programmer entry and believe a gut-check is enough to defend whatever behaviour comes as a result of their "experience."

Experience is more useful for selecting metrics appropriate to the audience. And "audience" is the best term for what might variously be a client, the boss, purchasing departments, end-users, whomever. It depends on the project, who pays, who needs to be happy, and experience plays a huge role in judging the dynamics. Judge well and you have a satisfied audience who will not only come back for more, they will recommend you to their peers.

Keywords: lazy programmer programming coder coding methodology