That's a tough one Al. It's far easier to point to examples of what isn't.

I have had a couple of occasions where I was asked to enhance other people's programming and found it to be a pleasure. It was well and intuitively constructed, used practical variable/subroutine names, reasonably commented, etc.
But the vast majority of programming that I have modified has been difficult to do, taking more time than it should have and leaving lingering doubt as to the efficacy of the revision (I could confirm 'fix' of the demonstrated bug but couldn't be positive that similar were fixed or that other bugs were not introduced by the fix).
The article shows a pair of code snippets that are functionally equivalent. I generally see similar to his bad example and very few of his good example.
My most unforgettable debugging was in a Fortran program where the originator had used playing card names for all of his variable names. It was hell!!!

None of the MS Office suites that I have worked with can be called non-crappy. Nor can I rate IE any better. And I personally don't "get" any of the "player" software that I've come across. Sure, they generally "work" but they do have lots and lots of puzzling aspects not to mention error descriptions that only a masochist could love.

I think it's safe to say the the Interface Hall of Shame wouldn't exist if the phenonema wasn't widespread. I do believe the article author's assertion that taking care of form/quality issues *in* the software essentially covers the interface/useability aspects too.


>Jim,
>
>What's your definition of acceptable (i.e. non-crappy) software?