March 12, 2002
The Iceberg principle

The Iceberg Secret, Revisited is an article by Joel Spolsky on why developers and users sometimes seem to be speaking different languages.

So, what's the secret? This:

You know how an iceberg is 90% underwater? Well, most software is like that too -- there's a pretty user interface that takes about 10% of the work, and then 90% of the programming work is under the covers. And if you take into account the fact that about half of your time is spent fixing bugs, the UI only takes 5% of the work. And if you limit yourself to the visual part of the UI, the pixels, what you would see in PowerPoint, now we're talking less than 1%.

That's not the secret. The secret is that People Who Aren't Programmers Do Not Understand This.

If the product is unfinished, says Joel, make sure it looks unfinished to the users. If you show them a user interface that's 90% finished when the underlying mechanisms are only 20% finished, they'll be unhappy at how long it takes to get the final product.

Posted by dcoates at March 12, 2002 10:58 AM
Comments

This is a very interesting notion because of the way it focuses on the differences between appearance (presentation) and real utility (function), and between selling a thing compared to using it effectively. This society constantly tells itself that "first appearances" matter. Sales and marketing presentations have raised the adage to something of a cultural commandment: "Thou shalt make a good first appearance." But what if what you're trying to "sell" so you can get funding is in a development stage? And what if the people who have the money don't really understand what you're trying to do? In a case like that, the person who has the flashy, finished-looking presentation package is going to get the money. What this article suggests is that it does so by inadvertently misleading the funder, who feels s/he's been "conned" by a false appearance of things being farther along than they really are. But of course the same funder would not support the same idea if the package reflected the state of development, because "they don't know what they're doing; it's a mess."

Thinking this on through, two things occur to me. The first is that the developer is really caught here, between a system that has developed a business standard requiring "false advertising" and the consequences of that practice. So where else is this a problem? And who's held responsible for the disappointment or breach of trust when the product fails to live up to the appearances used to market it? Apparently, the choices here are the developer or the funder (or seller/buyer) -- but it seems to me they are really both victims of the real culprit, which is this larger inability of ours to realize that first appearances are only part of a complete package, and that assessing something requires making a real effort to understand it -- not just a gut-level response to first impressions.

The second thing it makes me think about is the role of federal funding agencies such as NSF (the National Science Foundation). When the funding source evaluators are people who have been developers themselves, in the same area of work, the system shifts. Presentation and first impressions are still important, but not nearly like they are in a business situation. Reviewers and decision-makers tend to focus on the ideas, the utility, the stage of real development, the potential and so on.

I think I'm starting to understand why venture capitalists and other investors with money to spend on "something that will turn a profit without my having to work on it myself" turn out the sorts of things they turn out. And why federal funding for serious research and development is absolutely essential to healthy, real innovation. This is something I hadn't seen so clearly before.

Posted by: Dawn Adams on March 28, 2002 05:53 AM
Post a comment
Name:


Email Address:


URL:


Comments:


Remember info?