Brief Version

This site is my outlet for expressing the day-to-day frustrations I feel with web and desktop applications, the goal of which is to do so in a constructive fashion.

“If You’re Not Into the Whole Brevity Thing” Version

Way back when I was 15, I judged the quality of a programmer by how many languages he knew.

While working the graveyard shift at a Mobil down in sunny south Florida, a software contractor would visit at all hours; the prototypical hard-working, chain-smoking night owl. After fielding my many questions he waxed philosophical and laid this down - “It’s not about how many languages you know. It’s a toolbox, you learn to use the tools needed for the job.”

A lot of years went by until I finally got it. When I did, I stopped buying books on various languages and started down the path of software design (Refactoring, Design Patterns, etc.). What good was knowing all the hot languages if you were designing crap software?

Ouch!

If anything else, these books are humbling: a catalog of the mistakes I’d been making as a novice software developer. I’m not about to sit here and claim that that these books reinforced my many self-divined patterns (as so many Amazon reviewers are apt to do). Far from it. Sure I had developed a few good habits, but nothing like what I was reading now.

This Can’t Be Right

My first job out of school was maintaining and enhancing a Java-Swing-based graphical editing tool. Armed with a degree, knowledge of software design and good intentions, I felt I was ready to conquer Real World Development ™.

Strangely enough, our interface never improved. Sure we fixed a lot of bugs and added new features quickly and efficiently thanks to our great software architecture, but it never garnered any more praise than it did before. I was puzzled. We were fixing all of the issues and adding all of the features our customers asked for. What gives? Why did we keep getting dinged on usability?

Ah, Here’s Why

The Bay Area is heavily populated, but it’s a small town. I was in a French class with one of our customers (purely by chance) when I asked him what he thought of the interfaces our industry was producing.

“I know in advance it won’t do what I want, so here’s what would be best: I want a single window with everything the software can possibly do right there in front of me. Put toolbars across the top, bottom, left and right…”

…teaching me a valuable lesson: listen to your users, but don’t listen to them.

“Yeah, well, you know, that’s just, like, your opinion, man”

All software is designed, but very little software is designed. Our software had emerged from a collection of features rather than a holistic view of what it was, what it did and who it was for. It was all things to all people and any attempts to narrow the focus were met with well-intentioned preventative measures. Abstract concepts? Hide things? Won’t that hurt our users?

Additionally, too many UI discussions devolved into heated debates about what people felt was more or less usable (self-referential design) under the assumption that usability was just something we could hope for (treating design as guesswork… yuck). Being involved in these sorts of discussions was not fun. People’s feelings were frequently hurt… just general unpleasantness.

None of this was in my books on patterns and software architecture. What good is solid software design if you’re creating crap products?

Cooper, Norman, Nielsen et al.

Failing the time, foresight, money and patience to obtain a proper education in HCI or cognitive psychology, what can be done? Turn to the seminal works in the field and apply what others have learned, again with a nod towards accepting that I lacked the knowledge I needed to succeed.

I’m leaving a lot out here in the interest of preserving whatever claims to brevity I once held…

About a year later I ran into the CEO in our break room, “[Your group] turned a weakness into a strength.” A dubious remark, but pleasant nonetheless :-)

I’m a Programmer Too

Frequently I’ll criticize something as though it were “designed by programmers” which is self-deprecating since I’m a programmer myself. What I mean to say is this,

“The company responsible for providing this interface, decided design was not important and as such did not assign adequate resources towards that end. No one was responsible for design, so the burden was put on the developer.”

…which brings us back to where we started.

It’s All About Balance

A great architecture, reams of documentation, thousands of unit tests and an endless supply of talented engineers are only a portion of the product development process. Without treating design as seriously as you treat the other parts of your development effort, you’re destined to:

• Succeed in spite of a mediocre offering, but far less than you would have otherwise.
• Fail because you were unable to differentiate and a “me too, but one extra feature” competitor or worse - a competitor’s marketing campaign, bested you.
• Appear on this website :-)

The third option is to connect with your customers in a way your competitors can’t - passionately solving their problems while not burdening them with yours.