Geek Smithology

September 26, 2005

Listening to users considered harmful?

Filed under: Craft of Dev by Nathan @ 9:41 pm

I read a post over on Kathy Sierra’s blog that really hit a high note with me. Go read the article right now and come back.

Just in case you didn’t read the article, here’s a quote with the gist:

…we still assume that listening to real feedback from real users is the best way to drive new products and services, as well as improve on what we have. But there’s a huge problem with that — people don’t necessarily know how to ask for something they’ve never conceived of! Most people make suggestions based entirely around incremental improvements, looking at what exists and thinking about how it could be better. But that’s quite different from having a vision for something profoundly new.

True innovation will rarely come from what users say directly.

Oh my god that’s so true I almost peed myself. The (alleged) priority of my last company was to “build the brand.” The premier “brand building tool” was to become experts, champions even, in their business domain. There were Fortune 500 companies happy to outsource that part of their market research, but the company undercut its vaunted expertise by kowtowing to every client whim. Even when the client was clearly uninformed with ideas that could lead to misleading data. They also refused to admit that the company (a dot-com) could not succeed without a robust platform, but that’s another story for another time.

While there are bottom line concerns, several clients left because we gave them what they asked for, but it wasn’t what they needed. And to succeed, that is a distinction you must be able to make – the difference between what a client wants and what a client needs. Never ask a client with no domain knowledge (let alone expertise) “what do you want this report to look like?” Instead you ask “How do you want to improve your business?” Or (cribbing Kathy again) you need to look at each feature and ask yourself “How will this help the user kick ass?”

That is the kind of thinking that builds brands.

During the process of turning random client streams-of-consciousness into a reliable implementation blueprint, you need to crawl into every closet of the client’s business. Interview everyone you can about what they hope to accomplish. I can’t possibly frame it as perfectly as the pragmatic programmers, so again I quote:

Many books and tutorials refer to requirements gathering as an early phase of the project. The word “gathering” seems to imply a tribe of happy analysts, foraging for nuggets of wisdom that are lying on the ground all around them while the Pastoral Symphony plays gently in the background. “Gathering” implies that the requirements are already there — you need merely find them, place them in your basket, and be merrily on your way.

It doesn’t quite work that way. Requirements rarely lie on the surface. Normally, they’re buried deep beneath layers of assumptions, misconceptions, and politics.

Truer words about the requirements process have never been uttered. Your clients know only what they expect to accomplish, and if they knew all the details of how to implement it, why would they need you?

“But Nathan, client X wants everything their way, even if they are ignorant of the true consequences. What do we do about that, Mr. Smarty Pants?” That’s easy; you fire them! As Christopher Hawkins writes in his article 11 Clients You Need to Fire Right Now in the 09/05 issue of Software Development:

Sometimes it’s necessary to fire a client who started out promisingly, but is now offering diminishing returns – or devolving into downright bad business.

If you are building a brand on your expertise and a client is asking you to compromise your integrity for no other reason than because “that is what they want”, then they are not doing you (or themselves!) any favours, and you have to cut them loose, bottom line be damned. When you are in a position where you need clients more than they need you, your ship is sinking…fast! You must never confuse “the customer is #1” with “the customer is always right”, because that way lies madness.

When you go back to your work, ask yourself “How does this help the user kick ass?” If there’s no compelling positive answer, the time to change is now!

September 24, 2005

Idiomatic means Readable

Filed under: Craft of Dev by Nathan @ 11:29 am

Fatal error: Call to private method CodeColorer::performHighlightCodeBlock() from context '' in /data/5/0/134/72/297561/user/302314/htdocs/blog/wp-content/plugins/codecolorer/codecolorer-core.php on line 55