Coding Horror: When Writing Code Means You've Failed

April 27, 2005

When Writing Code Means You've Failed

I was chatting with a fellow developer yesterday, who recently adopted the very cool Busy Box ASP.NET progress indicator that I recommended:

We often need to provide a user message informing the user that their request is "processing". Like the hour-glass mouse pointer lets the Windows user know the system is busy processing their last request, I have a simple, clean, and effect solution to providing this on web pages: The BusyBox Demo

He was quite pleased with the results, as their app has to churn through some HR queries that take in excess of 30 seconds even after hand optimization. The psychological effect of a progress indicator is quite profound:

In cases where the computer cannot provide fairly immediate response, continuous feedback should be provided to the user in form of a percent-done indicator [Myers 1985]. As a rule of thumb, percent-done progress indicators should be used for operations taking more than about 10 seconds. Progress indicators have three main advantages: They reassure the user that the system has not crashed but is working on his or her problem; they indicate approximately how long the user can be expected to wait, thus allowing the user to do other activities during long waits; and they finally provide something for the user to look at, thus making the wait less painful. This latter advantage should not be underestimated and is one reason for recommending a graphic progress bar instead of just stating the expected remaining time in numbers.

My Busy Box recommendation came after that team made several abortive attempts to implement different kinds of progress feedback. And this got me thinking: sometimes, writing code means you've failed. So much of what we do already exists, and in more mature, complete form. The real challenge in modern programming isn't sitting down and writing a ton of code; it's figuring out what existing code or frameworks you should be hooking together. This is something Scott Swigart has also observed:

Venkatarangan points out all the stuff that Sauce Reader uses, showing that in software development today, 1/2 the work is finding the building blocks, and the other 1/2 is writing the glue.

The real development skill is correctly identifying which half is legos and which half is glue.

Posted by Jeff Atwood View blog reactions

« Give me parameterized SQL, or give me death Respecting Abstraction »

Comments

We've had similiar experience at work with processing boxes in .NET Web applications and it's amazing how much happier the users are when they know something is happening rather than wondering if the little IE flag in the upper-right of the browser is waving.

Brian Swiger on April 27, 2005 04:19 PM

I’ll go ahead and be the jerk who suggests that if your app needs a progress bar you’ve already failed.

I’m only half joking. Consider the waves that the Ajax approach (http://www.adaptivepath.com/publications/essays/archives/000385.php) has made. Before Ajax, ‘WWW’ stood for ‘World Wide Wait.’

Nils on April 27, 2005 07:02 PM

Now consider an Ajax app that pulls a large amount of data back (or a small amount over a slow connection): how do I know *anything* is happening without a progress indicator?

Tom Clancy on April 28, 2005 10:45 AM

This is great Jeff! I have found multiple "Legos" for my applications off of your blog! Agree with the thoughts on modern programming. Half of being a good coder these is how well you can google to bring up little goodies like this.

Nick on April 28, 2005 01:43 PM

> Now consider an Ajax app that pulls a large amount of data back (or a small amount over a slow connection): how do I know *anything* is happening without a progress indicator?

I agree. One of the many, many problems with this type of heavy client-side browser based app. And consider error handling..

Jeff Atwood on April 28, 2005 01:55 PM

I introduced a progress bar in one of my applications and it takes probably 10 milliseconds, not 10 seconds. Basically put whenever I run it, it's 100%. You don't see the "progress" though it does actually calculate and progress through each "stage".

It's one of those things I thought was cool at the time but it doesn't actually do anything special. It does let me know the action is complete though I take for granted that when I say "complete" it actually performs the action. I guess it's better to have something than nothing but in the future I'll try to test for that 10 second limit before doing a progress indicator. I tend to code what I think is cool more than what I think is useful though it does help me if not to give me that warm and fuzzy feeling.

Jeremy Brayton on April 28, 2005 06:07 PM

"if your app needs a progress bar you've failed".

how ridiculous can a statement be, half joking or not? i know of processes that would make all the world's supercomputers working in tandem groan under the strain, so it's senseless to decry something other than 100% responsiveness.

x on May 1, 2005 02:10 PM

> i know of processes that would make all
> the world's supercomputers working in
> tandem groan under the strain, so it's
> senseless to decry something other than
> 100% responsiveness.

This is an exception that proves the rule. Really, most of us are building business applications, not scanning the skies for communiqués from distant galaxies. It takes effort to tune an app to minimize wait times on long-running operations. It takes even more effort to design a UI such that the user doesn’t have to wait at all.

Obviously there are situations where a wait can’t be avoided because (a) you can’t decompose a given operation into enough background work and (b) you can’t squeeze any more performance out of the back end. I just think that most of the time we think we need a progress bar it’s because we’ve failed to do all that can be done to obviate a progress bar in the first place.

Nils on May 2, 2005 11:14 AM

Too cool, got a windows forms sample?

Greg Robinson on May 3, 2005 02:07 PM

--
"The corporate software architect of the future may have a function more akin to a plumber or a bricklayer than to a developer," said Barr in Seattle. "To keep his dignity intact, let's call him an assembler of components."
--

http://www.eweek.com/article2/0,1895,1925437,00.asp

Jeff Atwood on February 13, 2006 10:31 PM

Nils
Progress bars will always be important especially in todays utube,facebook world where users upload larger and larger files or wait for files to download. Also (to come closer to your biz app scenario) comparison sites (e.g. insurance) have long waits for data to aggregate from several sources.
You don't need to be scanning the cosmos for ET to set off a long running process.

EscapedFromDaZoo on January 12, 2008 04:02 PM

The plural of lego is lego.

Sorry, this is normally the sort of pedantry up with which I shall not put, but for some weird reason, I find "legos" just so utterly horribly wrong and stupid sounding it bothers me enough to pipe up.

steve on April 23, 2008 09:48 AM