aaron evans

I’m reading Joel’s book Joel on Software. The book is fun to read and I agree with most of what Joel has to say. A lot of the content is five years old but most of it doesn’t sound dated.

Joel has some annoying tendencies as a writer that bothered me. The most annoying tendency I’ve found is the repeated use of the strawman argument. He has some other annoying tendencies but the book is nevertheless a fun read.

I just read the chapter title The Iceberg Secret, Revealed and it may be my favorite, perhaps just because it’s a bit of a rant against MBAs running software projects. Here is a nugget:

If there’s one thing every junior consultant needs to have injected into their head with a heavy duty 2500 RPM DeWalt Drill, it’s this: Customers Don’t Know What They Want. Stop Expecting Customers to Know What They Want. It’s just never going to happen. Get over it.

Instead, assume that you’re going to have to build something anyway, and the customer is going to have to like it, but they’re going to be a little bit surprised. YOU have to do the research. YOU have to figure out a design that solves the problem that the customer has in a pleasing way.

This is funny. With respect to design of any product, I can identify the following models for designing products:

1. Safety Through Mimicry: When design is done by committee, no one wants to propose an original design that is contentious and be wrong. That’s a good way to lose your job. So, simply point to something else that appears to work (your previous product or a competitor’s product) and copy it. This model effectively avoids all of the perils of designing a product. Unfortunately, you’re never going to build anything that people want and can’t get elsewhere.
2. Safety Through Market Research: The design committee has an original idea of combining features of popular product X and Y and calling it Z but nobody wants to risk making Z without knowing, in advance, if the design will be popular. Enter market research. This is a good way to validate what customers want today. Unfortunately, the product you’re building won’t be ready for sale for another 18 months.
3. Non-Safety Through Original Design: In this model, there is no design by committee. Instead, you have a few highly talented people with tremendous power over the design of products who identify what they believe will work in the marketplace. Prototypes of new products are built and market research may be used to see what public reaction will be to the product. If the product fails, no one is fired but lessons are learned.

In any event, Joel’s iceberg chapter is primarily focused on the notion that software is much like an iceberg in that you only see 10% of it. In other words, about 10% of the time spent designing software relates to what it looks like. I think this might be a bit low but perhaps in Joel’s domain it is true. I’d probably push the 10% to 15% or possibly even 20%. It really doesn’t matter; the point is that an overwhelming majority of the time spent designing a software system relates to how it works rather than how it looks.

Joel’s claim is that non-programmers simply do not understand this. Joel lists some interesting corollaries of this claim. For example, if you show business people a mock-up that looks great, they will assume that the product is just about done.

Joel’s solution to this misunderstanding is to simply not show non-programmers the UI for uncompleted features. Joel also recommends that managers make sure that everyone knows how development is progressing with respect to the schedule, not the ui. This, of course, assumes you have a schedule for your product that engineers have agreed to. If you lack such a schedule, your project is more or less hopeless.

This entry was posted on Sunday, April 15th, 2007 at 9:51 am and is filed under Development. You can follow any responses to this entry through the RSS 2.0 feed. Responses are currently closed, but you can trackback from your own site.