Eli Robillard's World of Blog.

GenericDB gets the coolest fans. Jack Bellis just created GenericUI, a stylesheet and graphic element package to help non-designers build better looking interfaces. Like Chuck Speerly's Custom Buttons for GenericDB, this is a way to "professionalize" any UI.

Dig deeper and you will find that Jack is a busy guy. He co-authored a 5-star book on Repetitive Stress Injury, makes sculpture interesting, and wrote a respectable free booklet on Interface Design.

Haven't seen GenericDB yet? Then you're missing the easiest way to put a database online with Classic ASP. Check it out!

Learn how to build software that people love to use. Understand why meeting "user requirements" leads to software people hate. Software needs to listen and react appropriately -- with taste. Warning: This article is designed to make you think.

http://dotnetweblogs.com/ERobillard/Story/4479.aspx

[Originally posted March 31, 2003. Edited September 14, 2003]

Last month I tried the same test and came out HP-UX. I lost the link, just did it over expecting the same result to paste here but damn: 

 
Which OS are You?

I'm a believer.

See also: the half-dozen posts on "lazy programming" below.

Start trading on the blogmarket. World of Blog was up to $222 on March 25 and sits at $100 today, a little volatile but not too shabby. Will Shatner still do ads for stock?

Last Week: The Lazy Programmer (1LF, 2LF, 3LF, 4LF)

This Week: The Lazy Programmer (5LF)

It's been an interesting week. Looking forward, it gets even better.

"TouchGraph provides a hands-on way to visualize networks of interrelated information."

Go. Play. Now.

Touchgraph Google Browser

This is an awesome tool for checking the "entrenchment" of a given site. I recommend setting Radius to "ALL" for the primary URL. Now that's a site map. Double-click any other node and watch the next level of relations explode. Hit Clear to start over with a new site.

There is also a downloadable Touchgraph Wiki-browser.

Regular readers of Joel on Software will know that Joel posted a terrific article on Building Communities with Software. He built a simple moderated Forum app that removes barriers to posting (like registration). His article describes the rationale behind every step of the the design, and for an online forum intended to provide software support, it is a good model. As a community-builder, I'm not so sure. But that's fodder for another day.

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.

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