« Broken Gnome, part II | Main | 1:40:01/155 »

February 10, 2006

Defeating Feature Fatigue

Janetta suggested I read Defeating Feature Fatigue, an article that appeared in Harvard Business Review of this month. Roland T. Rust, Debora Viana Thompson, and Rebecca W. Hamilton studied the effects of featuritis on short-term to long-term sales, finding that although feature richness attract folks who haven't yet tried a product, too many features reduce long term sales as even expert users suffer from the complexity of a single product with so many capabilities.

How well does something clearly true for telephones and DVD players map to software? Probably quite well for end user software, like browsers, mailers, and web applications. But what about the software used by people making that end user software or the software and hardware to support its use?

Probably a lot of the same findings still hold. Eric S. Raymond wrote up The Art of Unix Programming, including Basics of the Unix Philosophy, which has perhaps too many rules (17), though they all seem to have the same basic flavor. One that fits the context of this article is the, "Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do."

When we create without knowing what is needed, it makes sense to take a shotgun approach to features. After all feature richness attract folks who haven't yet tried a product, all other things remaining equal. Perhaps the way to Defeating Feature Fatigue for software lies in knowing precisely what it needs to do, and focusing on that. Easier said than done, especially when you're competing rather than cooperating.

Posted by Mark at February 10, 2006 09:45 PM

Trackback Pings

TrackBack URL for this entry:
http://mcraig.org/movabletype/mt-tb.cgi/1340

Comments

From a reader's letter in vol.47 no.5 (May 2004) of Communications of the ACM:

LOC [Lines of code] was once considered a good measure of development cost, a notion properly debunked by [Pillip] Armour at the end of his column ["The Business of Software," March 2004]: "The strongest independant correlating indicator was the number of customer-initiated change requests received in the first month of the project."

The number of such requests measures how well the requirements are understood. Experienced programmers typically have a better understanding of the problem domain and its tools, so their development costs are lower.

Sorry for the long reference, I can't find it on the web, and if I did it would probably only be for ACM members. This excerpt was typed from a copy (digital photo, actually) I made of a page of the magazine, which I found on the library free rack.

I haven't even read the contents of the original article, but this reader adds an interesting twist: feature creep increases cost, especially because it happens after the requirements were thought to be understood. The sad conclusion is that there is a failure to understand customers. However, I think the reader is wrong to assume that experienced programmer can solve this, because I don't believe, and he gives no argument, that programmers understand customers. However-however, I would defend them by saying they shouldn't have to because that is the purpose of marketing.

Posted by: Andy at February 15, 2006 11:05 PM