Development Methods in the real world.

Shane Hathaway shane at hathawaymix.org
Wed Sep 26 12:22:23 MDT 2007


Dave Smith wrote:
> Charles Curley wrote:
>> Customers?!? Customers don't know squat about good software. If they
>> did, they'd be writing the project themselves. Why would I ever want
>> to talk to them?
>>   
> 
> I agree 100%. From Joel Spolsky:
> 
>    Customers Don't Know What They Want. Stop Expecting Customers to Know 
> What They Want.

Many of Joel's articles are high quality, but this one is a rant.  It's
true that bad customers don't know what they want, and you should avoid
business with bad customers altogether.  Good customers, OTOH, know some
of what they want, and it's the developer's job to help the customer
understand how to accomplish it.

> Put yourself in [the customer's] shoes. Imagine that you've just made 
> $100,000,000 selling your company to Yahoo!, and you've decided that 
> it's about time to renovate your kitchen. So you hire an expert 
> architect with instructions to make it "as cool as Will and Grace's 
> Kitchen." You have no idea how to accomplish this. You don't know that 
> you want a Viking stove and a Subzero refrigerator -- these are not 
> words in your vocabulary. You want the architect to do something good, 
> that's why you hired him.

Customers that have $100M burning a hole in their pocket are too rare to
care about.  A frugal, smart customer would put in a lot of time to
understand the field, with the help of the architect.

> The Extreme Programming folks say that the solution to this is to get 
> the customer in the room and involve them in the design process every 
> step of the way, as a member of the development team. This is, I think, 
> a bit too "extreme." It's as if my architect made me show up while they 
> were designing the kitchen and asked me to provide input on every little 
> detail. It's boring for me, if I wanted to be an architect I would have 
> become an architect.

This is indeed too extreme and it illustrates why development teams need
to customize whatever methodologies they choose.

Shane




More information about the PLUG mailing list