Agile Windows Programming: Big, Simple, Stupid

Microsoft and friends, I love you guys. Really I do. I've been with you for a long, long time now. But I can't help notice that every freaking thing in windows programming has a more options than a Wall Street derivatives trader.

I like options, really I do. But when I click on a Telerik ListBox and see this? Somewhere we went off the rails.

What is the real value of this level of detail?

When I train .NET developers, one of the first things I have to deal with is their overwhelming sense of being lost by all the things they can do in the IDE. It's not just a button, it's an image, it's a video, it's 3-D, it's beveled, it's filled with a wash, etc. For all I know it makes jullianne fries.

My answer to them is usually very simple: focus on the user stories/use cases and their goals. I wonder if that advice is not too simple.

I understand and admire the programmers who are putting these interfaces together. Friends, I am one of you. I never met a program that I couldn't load up with a million options. After all, by the time I was finished coding, I was a super user. And who else should programs be written for except super users?

But having grown a tiny bit wiser, it occurs to me that too much freedom is as bad as too little. When I use the iPod I only have a very few controls on the screen at any one time. Each one is intuitively obvious and responds to touch. I like that. Big, simple, stupid. The program does one simple thing, easily, and it makes me happy.

As a Win32, COM, and C++ programmer, I understand all the cool, marvelous, and complicated stuff going on behind the scenes in an average windows program. It's a teriffic sense of power the programmer has once they are aware of the neat stuff they can do simply by using other people's code.

But as an iPod user, I also now understand that my job as coder is to mercilessly strip out everything I possibly can that does not relate to the one or two simple reasons an average user is using my program. "Keep It Simple, Stupid" doesn't even begin to cover the degree of diligence I have to pay to accidentally overcomplicating the UI. It's like the web design book said: to you, every little pixel on your website is important. To the average reader, it's like they are driving by your website at 50 miles-per-hour in a car. It's got to be big, simple, stupid.

What happens -- and this happens to a lot of programmers -- is that you're building this uber-simple User Interface and you innocently enough click on one of the property pages, like the one above. Suddenly you're in a world where all of your anal-retentive graphic designer fantasies can come true. Should that be an inner bevel on the sub-control? Or would a drop shadow be more effective? It's like the problem of paining the bike shed -- when something doesn't matter suddenly everybody has a profound opinion about it. And hey! This is a lot easier than trying to figure out that persistence problem that's been bugging you for days. And if you're working at this level of detail, surely your user can handle a few more options, right?

Some people are going to latch onto my adjective "stupid". Programs shouldn't be stupid -- that's a pejorative term. But yes, they should: one of the few indicators that you're working at the maximum level of simplicity is that you will view your UI as the most ridiculously stupid thing ever. If your User Interface is easy enough for one-eyed, one-fingered, one-armed, lobotomized, drunken monkeys? You might be close.

Some agile folks are going to point out that a Product Owner in the room will help fix this. I am not so sure, however. This is a disease that infects everybody. It's insidious. At the beginning of the sprint you're talking about user goals and needs and by four days in somehow the main question is serif or sans-serif fonts for the section headings. These things usually don't escalate to the entire group -- people at least unconsciously realize how silly they are. But you can spend a lot of time with your pair and the product owner going over non-essential details without realizing it. And I'd even wager that most product owner time is spent that way, since most business people aren't graphic designers either.

I don't think there is an easy answer to this, because there is always going to be that one-in-a-million situation where you really needed to change the font weight on a nested ListItem. Just like anesthesiologists always have to be on guard against becoming drug addicts, perhaps we as programmers must always be vigilant to keep from spinning off into the weeds of detail.