Lazy Programming III

I am still finding prior references to lazy programming, each with a slightly different and useful perspective to add. The most interesting part for me is that several people have come up with roughly the same idea independently and put it into similar words.

Today I bring you the "Lazy Programmer's Guide" by Jeremy Bowers. He defines a numbers of pieces which combine to form a style with this goal: "The Lazy Programmer wants to minimize the time spent on all tasks... and is willing to go to great lengths to accomplish this goal."

Jeremy discusses friction and cites encapsulation in OO languages as a way to overcome it and increase fluidity. His data validation section is good reading (with parallels to Second Lazy Form plus a more comprehensive example). And his sections on "selective verbosity" and "selective brevity" are well-written pieces that go beyond the basics of Refactoring to teach the "how" and "why" of clean code.

Today, Chad Osgood's Blog relates his suspicion that laziness is bad when characterised  by the "it works" mentality. People who ask, "Why refactor when 'it works?'. . . . A lazy programmer would ignore the need to refactor. A lazy programmer would ignore the broken windows until it's too late." It is good that people are questioning the idea and following along because this is still just the beginning. Chad's concern is fine, but limited to people who stop after First Lazy Form , and I'd like to point out that no one should stop table design upon reaching First Normal Form either.

Like Perry Farrell sings, "ain't no wrong, ain't no right, there's only pleasure and pain." Lazy Programming isn't something to accept or dismiss, it's a way to describe what people already do, and the varying levels to which software issues can be solved. To ascribe wrong or right-ness to any level is pointless. In the long-run for a given app, some solutions work and some don't. Some bring pleasure, some cause pain. In an app that only exists in the short-term and will never be maintained, band-aid code may be the most efficient choice. Other cases call for longer-term efficiency. Strong  programmers look for excuses to take it further, weak ones look for excuses to stop. Dat's all.