What do these posts have in common?:
If you get it wrong, the voice comes on the line to tell you. Hey, since you know what I did wrong and you know what I meant to do, why not just fix it? If I dial a number and forget the “1″, just insert the 1 and connect the call. If I dial a number and include the “1″ when I didn’t need to, just delete the 1 and connect the call. Don’t make me have to look up in the book whether I need a 1 or not. (In the front of the phone book are tables showing which numbers need a “1″ and which don’t. I hate those tables.)
(Yes, I know there are weird technical/legal reasons for why I have to dial the phone in four different ways depending on whom I want to call. But it’s still wrong that these technical/legal reasons mean that the rules for dialing a telephone are impossibly complicated.)
http://blogs.msdn.com/oldnewthing/archive/2006/11/27/1160055.aspx
Every time you want to leave your computer, you have to choose between nine, count them, nine options: two icons and seven menu items. The two icons, I think, are shortcuts to menu items. I’m guessing the lock icon does the same thing as the lock menu item, but I’m not sure which menu item the on/off icon corresponds to…
Inevitably, you are going to think of a long list of intelligent, defensible reasons why each of these options is absolutely, positively essential. Don’t bother. I know. Each additional choice makes complete sense until you find yourself explaining to your uncle that he has to choose between 15 different ways to turn off a laptop.
http://www.joelonsoftware.com/items/2006/11/21.html
Both talk about decision making processes that may be reasonable in themselves, but lead to unreasonable conclusions. From the detail-oriented, rule-following side, it may make sense to display 25 menu options so that 99% of users have the functionality they need. However, the details are always there to support the whole, and not the other way around. If you design a multilingual sign, for example, the marginal benefit of adding another language may outweigh the cost, but continue on this calculation for too long and you get something like this:
Hype often glorifies romanticizes process over results. Think Agile Development, or Ruby on Rails, for example. The Daily WTF has many such examples (web services for one). Which leads to a rule of thumb: Make sure the results justify the methods you use.
In the end, processes are only remembered by the results they produce, and products are remembered by how good they were as a whole. Usability is important; development methodology is important; language is important; design philosophy is important. But like the works of a great artist, good software is not judged by how many rules it follows. We see results first, and only then do we find rules to explain their beauty.
Photo credits:
(http://www.pjchmiel.com/photo/misc.html)
(http://en.wikipedia.org/wiki/Johann_Sebastian_Bach)