Fog Creek Software
Discussion Board




Raise Your Hand If You Disagree with Joel

Okay. I’ll step up to the plate, here. I tend to agree with the vast majority of what Joel writes. The VAST majority. The Iceberg Secret, however, reads as if he took a few too many grumpy pills yesterday morning. I don’t even know where to begin with my response, but perhaps it’s best to target Joel’s early admission that “since I started working in the software industry, almost all the software I've worked on has been what … software … not being built for a particular customer.”

I can almost imagine Joel in a smoke-filled bar, pacing back and forth across the stage, pensively rubbing his eyebrows before he delivers the next line: “Have you ever noticed (pause for effect)… that on these custom projects (another pause) the customer didn’t know what they wanted?”

The crowd roars. “Right on!” they shout. “More, more! Customers suck! If it weren’t for all of our customers, we could get so much work done!”

In my imagination, the scene suddenly changes to the “Squirrel Jokes” episode of SpongeBob SquarePants, the crowd eating up all the references to the ways customers always change their mind, or don’t know the difference between a user interface and a functional application, or they’re not happy when we give them what they EXPLICITLY ASKED FOR, even if it’s not what the wanted. Stupid customers. They’re so gawl-durned stoopid.

For the record, I’ve been fortunate enough, in my ten some years in the software industry, to have worked almost entirely on custom-developed solutions. It is amazingly arrogant to assert that “customers don’t know what they want.” They may not know how to ARTICULATE what they want in a way that YOU’RE able to understand, but believe me, they do know. Even your Will and Grace kitchen example illustrates someone who knows EXACTLY what they want, but might not have the vocabulary. So he relies on the architect to EDUCATE him, to show him samples, to say “this is a Viking stove,” and “this is a Subzero refrigerator.” How cool would it be if the architect listened politely, then “went dark” (to borrow a term from McCarthy’s Dynamics of Software Development), came back with a mostly completed kitchen, and expected the customer to like it?

Oh, sorry. I forgot: according to Joel, “you’re going to have to build something anyway, and the customer is going to have to like it.”

* sigh *

Let’s take a quick look at Joel’s three variations of “the customer didn’t know what they want,” before making a suggestion.

1. “The damn customer kept changing his mind.” As a consultant, you need to be the sherpa guide. It IS your responsibility if your client decides he wants to go in a direction that you know is unwise, and ends up falling off of a cliff. It is your RESPONSIBILITY to assert your wisdom and experience, and keep the customer from hurting themselves. That’s why they hired you.
    
2. “We built it EXACTLY THE WAY THEY WANTED.” Or the way they thought they wanted it before they knew what was possible, or before the business changed because it took so long to build the system, or, worse, they way that YOU interpreted what THEY wanted. I’ve yet to see a detailed spec document that can’t be misinterpreted. That’s the other part of your job: constantly ensuring that your INTEPRETATION of a thing matches the customers EXPECTATION of the same thing.
    
3. “Our miserable sales person agreed to a FIXED PRICE CONTRACT…” Oh, I get it. Let’s blame our customers either a bad decision by the sales person or management, or a lousy process that allows a sales person to put together a fixed bid without consulting with any programmers or architects. This has nothing to do with the customer, and everything to do with your own company’s staff and/or policies.
    
* double sigh *

Here’s a suggestion for version 2.0 of the Iceberg Secret: delete everything after the fourth paragraph. Everything.

You’re exactly right, Joel, that there is a problem with communication in software management, and that you’re more successful when you’re able to translate between Programmerese and MBAese. But maybe instead of a tirade that only serves to widen this gap further (also see all the “right on!” responses that have been posted, and all the developers who now feel vindicated, that they continue to be right and the customer continues to be wrong), you should consider writing a lesson on the importance of learning a foreign language.

I shouldn’t expect a business manager to understand the problems I’m having debugging my COM object when I only have access to test data any more than I should expect a conductor on a train from Calais to Paris to understand me asking where I need to get off if I want to transfer to Rouen. If I learn a little of his language, demonstrating even the smallest glimmer of respect, he might respond by using a little bit of my language. In the end, hopefully, we’re COMMUNICATING even if we don’t completely understand one another.

Robert K. Brown
Thursday, February 14, 2002

He could keep the 5th paragraph too.

Christopher Wells
Thursday, February 14, 2002

[raises hand]

Good analysis, Robert.  I've never read a Joel article before that has left me so full of "WTF was that?"  It was like reading something by Philip Greenspun, for gawd's sake.

rOD.

rOD
Thursday, February 14, 2002

It seems many people on the discuss thread should be posting here.
A while ago I had the same contempt for the ‘customer’. They are not sheep that come to you to be sheared. We must realize, pay our salary.
Customers do not know what is possible. What they want is something that helps them get their job done.
If my customers knew what was the appropriate technology to handle the amount of data, the throughput, the gui, etc., why the hell should they pay me? Wouldn’t it be great if some customer could write the perfect specification? Just add programmers and the complete system emerges six months later. I would write a specification to code translator and low bid all of you.
I can’t remember the book but here is some real advice, no more rants. It was in either “The pragmatic Programmer” or “Code Complete”. Write code in terms of the domain. To me this means, figure out the words for concepts in the users world.  Write the application as a scripting language using their terms. When they say, “I need to recalculate the fluber, to get wizzbangs per hour.” You do "result = convert(WizzbangspHr, recalc(fluber)).
This is one of the ideas in software that is so obvious nobody does it.

Doug Withau
Thursday, February 14, 2002

My experience has been that the customer always knows what they want. Mostly they do'nt care how they get it.
The 90% of the iceberg stuff is entirely up to the development team. If I have a GUI that the customer hates in a demo I soothe their fears by making vague but serious promises and move on.
Demonstrations are but a moment in time for a long term project - keep moving and you'll get the job done.

Tony
Thursday, February 14, 2002

[hands on the ground]

Customers don't have a clue what they want or need. They have very little understanding of cost-benefit analysis and have no appetite for push-back. The most successful product managers are those that effectively balance customer input with product sensibility. Customers don't understand that each feature request must be spec'd, prioritized, developed, tested, maintained, enhanced, worked-around, etc. etc.

pb
Thursday, February 14, 2002

I don't think I read as much negativity in the article that some others have. 

I didn't understand the point to be "Customers are lame", but instead "Stop making unreasonable assumptions about your customer, and here's a few tips to help manage a non-technical customer's expectations."

rich
Thursday, February 14, 2002

The key to enjoying this article is to read first 4 paragraphs, then skip down to corollaries. The things in-between are just "grouchy-before-morning-coffee stuff" :-P

-thinker-
Thursday, February 14, 2002

There's a skill which good programmers possess, but which many competent people lack: stating a step-by-step high-level procedure for what they want to do. Many customers can't think procedurely, though they can readily look at the finished product and point out flaws. Meanwhile, too many programmers expect someone to hand them perfectly accurate and stable requirements in advance.

You've got to understand the customer's activities and the pain they feel, and then find a way to alleviate the pain without causing any new pains. That's the only way you can provide a useful solution.

At my last company, I was building tools to simplify the internal release process, which I had struggled with previously. Since I was well aware of what the problem was, I managed to design tools that made the release process a lot simpler, both for myself and for the rest of the company.

Of course, you generally don't have that kind of direct knowledge of what the customer wants. In the case, listening to the customer and rapid prototyping can really help.

Jared Levy
Friday, February 15, 2002

Last year I built an application for a neurosurgical department of a major NY hospital.
It basically read data files produced by a scanning device and produced pretty pictures for the surgeons.

Let me assure everybody - THEY KNEW WHAT THEY WANTED. I was the dummy.

Tony
Friday, February 15, 2002

It truly is a humbling experience to basically write a shell around some abstruse activity that the client understands and you never will.  Its also peculiarly freeing.  I always wanted a dextrous skill such as carpentry or plumbing, making a simple application is the nearest I get to that.

Its also sometimes a great ego boost to share in a client understanding something new about their own processes, its also pretty rare. 

Simon Lucy
Friday, February 15, 2002

I think that one of the things that leads to problems is the tendency to forget who the customer is.  Invariably a product, even a custom product, has a wide range of clients with differing priorities and needs.

As a developer, your clients normally include the end user, the purchaser, your management, and yourself.  To make everyone happy, you need to balance all of your clients needs.

The largest issue with this is that you rarely get the insight you need into the clients environment.  Somewhere between you and the knowledge you need stand contracts people, marketing, and development boards that have decide how things work without necessarily investigating the practicality of their proposed solution.

Always get the input of the real stakeholders.

!
Friday, February 15, 2002

I think Joel is trying to write "Peopleware II."

That is: How to apply an understaning of human nature to the customer interaction aspect of software development.

Substituting a Dale Carnegie course for your next technical course might make both you and your customers happier.

tk
Friday, February 15, 2002

I've got to agree with Joel here. Customers think they know what they want, but they are mostly guessing. Example: "Sometimes, I select an object, and then click a button to change it. I want a foot pedal, so that when I hold down the pedal, I click the change button first, then all the objects I want to change." This is really a request for multiple select of objects, not a request for a foot pedal that reverses the object-verb paradigm.

I'll outright argue with a customer over UI issues that are purely UI issues. I will discuss requirements with a customer for hours to get a deep understanding of what business rules I need to implement and which are not really business rules at all, but side effects of processes that my software will obviate. I keep my mouth shut if I think the core business rules are stupid.

Jeff Paulsen
Friday, February 15, 2002

There are two issues that are being tossed around here:

1) The customer can’t write a good spec
2) Writing a good spec is the job of the developer

Lets assume that the customer could write a perfect spec of exactly what they want. Joel’s point here is that if you follow the customers perfect spec you can wind up with a piece of crap.

The issue here is NOT that customer can’t write a good spec. The issue here is if you do things exactly the way the customer wants you *can* wind up with a piece of junk.

In other words, everyone here is auguring that the customer is not good at telling you what they want. This is nonsense. The real issues here IS FOLLWING and doing exactly what the customer wants.

I also suspect that this is why the article struck such a nerve. That nerve is in fact that statement that we developers know better.

Well, fact is...really good developers *do* know what is better in many cases. Maybe the lousy developers don’t. We are not talking about *all* cases. Many ideas and procedures the customer has, needs, and their requests are going to be real good. I have no problem with this.

Lets not mush the issues around the customer not being able to write a spec. We are talking about internal customer tasks that they are attempting to accomplish. The procedures (non software), and how information moves around  (before any software is written) is the issue.

In virtually every software project I have worked on there is a portion of procedures and ideas that if followed would make for a poor system. Since every project has a good portion of procedures that if followed will result in poor software, then the only reasonable conclusion that the customer does not know what they want. This is assuming that a perfect spec could be written by them.

We are not talking about software here. We are talking about how the business is going to accomplish a task. When I write great software I don’t just implement the customers requests....I wind up changing the way they run their business.

Any developer who does not change the way a business accomplishes it tasks is not doing their job correctly.

Sorry, I have to Vote with Joel on this one...

Albert D. Kallal
Edmonton, Alberta Canada
Kallal@msn.com

Albert D. Kallal
Tuesday, February 19, 2002

Albert Kallal says:
"Any developer who does not change the way a business accomplishes it tasks is not doing their job correctly."

Albert makes a good point.  A good developer is as much a domain consultant as he is a technical resource.

Note I said a "good" developer.

Norrick
Thursday, February 21, 2002

At times, it is reasonable to use the programming process as a means of understanding what the customer wants. Simplistically, every programmer wants complete, perfect specifications but, in the real world, this usually is not possible (and the programmers don't relialize this).

The real problem occurs when the customer expects the programmer to guess what the customer wants (by telepathy, reading tea leaves, or whatever) and is upset when this is can't be done.

njkayaker
Saturday, February 23, 2002

I really liked this article, but a couple of thoughts struck me as I was reading it.

One. Now that CityDesk is out, Joel *is* building a product for customers. Through the CityDesk forum he's getting tons of feature requests, and he's probably spending a lot of time trying to figure out what it is we all really want. Since the forum doesn't begin to approach "functional specifications" or "business requirements" he's having to decipher a bunch of complainy feature requests.

We're the Customers who "Don't Know What They Want."

Two. He's articulating a communications problem from a developer's point of view. I think it's a little arrogant to assume that "we know what you want better than you do," but he does a good job of describing the frustration most of us feel when trying to build something for someone. This is why there are books written about the requirements gathering process.

The danger here is that someone who follow's Joel's advice might start to get enough hubris to believe that he knows what the customer really wants, and when it gets delivered, is nothing like what the customer really wants. "You asked for a widget right? Well, this can do widget, it can also do a dozen other things."

I see my job as a developer to continually ask myself and the customer "What is it you really want?" To continually step back just a little bit and try to see the bigger picture. The customer might ask for feature "A" because they assume "A" is the only way to do things. So I step back and say "Hmmm. A seems good, but isn't A just really a means to an end?"

For example, let's say I'm building a product that lets people update information in a database, and the client asks for a field that they can put a filename into. "This way they'll know where to go in the file repository to find the related document." I might say to myself "Sounds like they should be able to create a link to the file repository, or perhaps even upload the document itself to the database."

But I would never build that feature in without explicitely asking the client if that's what they wanted. If I was smart I might build what they asked for, with the ability to easily add in linking or uploading.

Like Joel I assume the client might not know exactly what they want, or how to put it into programming terms, or perhaps that they've made certain assumptions about what can be done. Unlike Joel I assume that if you can figure out exactly what it is they want, and clearly, effectively communicate it to them, they'll "recognize it when they see it."

In Joel's world, it seems, it's better to keep the customer in the dark. In my world you surprise the customer at the very beginning, perhaps before any coding gets done, or in the middle when you realize that there is a better way to give them what they want.

Those of you who use CityDesk, how does it feel to not know what you want?

Mark W
Sunday, February 24, 2002

>We're the Customers who "Don't Know What They Want."

We are talking degrees here. When Joel’ made the product he had no feedback from us customers. Of course now he has to listen to the customers. This really is a chicken and a egg problem. It just really depends on who he listens to, and what he decides to implement. Only he can decide this and not the customers. In addition, it was not the customers who came up with the idea for CityDesk.

We really are talking about innovation here. Every person wants great family transportation. It took some real genius to come up with the Mini Van. Yet now, all families know they want a Mini Van. They did not know this until the product came out. For sure the auto maker has to listen to things about color, and what kind of seats. However, just like Joel’s city desk the customers had not used a similar product before. So, yes, once the innovation has occurred, then you can certainly listen to the customer about little things like color etc.  All the customer ideas in the World are not going to change the basic idea of how CityDesk works.

>The danger here is that someone who follow's Joel's advice might start to get enough hubris to believe that he knows what the customer really wants, and when it gets delivered, is nothing like what the customer really wants. "You asked for a widget right? Well, this can do widget, it can also do a dozen other things

Well, that is a danger...but only if you don’t know what you are doing.

>Those of you who use CityDesk, how does it feel to not know what you want?

It feels great. In fact, I can’t think of *ANY* kind product that can get me excited unless it has some innovation in it. In other words, if it is exactly what I want...then it will probably be a mundane product. How can anyone get excited over something with no surprises?

Every time I use a spreadsheet I think of incredible innovation that this idea was. The financial community had no idea what was about to hit them. Now that we have all used spreadsheets it is a no brainier.

So, yes..the most exciting and interesting products are those with ingenious innovations built in. In general these innovations are ones that I did not think of and thus make the product most interesting and enjoyable to use!

So, how does it feel to use a product like CityDesk with great ideas and innovation?....just great thank you!

Albert D. Kallal
Sunday, February 24, 2002

I disagree with your premise that the article is about innovation, it's very much about about creating a product to fill a specific need, as articulated by a customer. I also disagree with your conclusion that the software needs to be innovative, or get you excited. When you're building for a customer, you have to fill their need first. An innovative product that doesn't fit their need won't fit the bill. More on this later.

Your assertation that it's only dangerous "if you don't know what you're doing" is, in my mind, insulting, and arrogant. It also creates an air of superiority, as in "there are those who get it and those who don't." I thought Joel on Software was a place to learn and share, not be preached to, though I could be wrong.

Joel addresses well managing expectations through prototypes, and I really enjoyed this part of the article. What I disagree with is his handling of communications with the customer.

Yes there are difficulties when it comes to expressing, as a layman "with his nose too close" to the subject matter to explain it to someone who doesnt know, what you want to a highly techinical person. There are also difficulties, as a person with little to no background in the customer's given field, to understand what it is they need.

Joel's answer seems to be "They don't know what they want, don't listen to them, don't involve them in the process, magically intuit what they want and give it to them."

Your Minivan example misses the numerous studies that said people wanted a vehicle that was larger than a wagon, yet smaller than a van. Lee Iacoca gambled on the Minivan, but there was extensive research to back his decision.

What really needs to be addressed here, and Joel readily admits that he's not a subject matter expert, is how, as a designer/developer/architect/kitchen builder, to come to an understanding of what it is the customer needs. I don't accept your "only if you don't know what your doing" and Joel doesn't offer anything in way of explanation on how you know what it is they really want.

He also doesn't address the need for you, as the developer, to explain your rationale to the customer. He also seems to imply that this only needs to happen *after* the thing's been built.

In summation: The customer doesn't necessarily know how to articulate what she wants. The developer has to figure out what the customer wants, but how? I think a lot of people will be thrown off by this leap from customer not knowing to developer knowing.

Requirements gathering is an art and a skill, and you and Joel both seem to (as does most of the programming world) think it's not important.

To balance out the Joel scorecard, see Painless Functional Specifications:
http://www.joelonsoftware.com/articles/fog0000000036.html

Perhaps he does care about giving the customer what they want, not what you think they want.

Mark W
Monday, February 25, 2002

I agree that article is not only about innovation. However, you question was how does it feel to use a product with features and ideas that I did not come up with. The answer to that question is simple.

As for the mini van example, it is a good one. It is really hard to believe that “all of a sudden” this data came up that said people want something larger than a car...but smaller than a van. (it used to be called a station wagon). It took the auto industry more than 40+ years to come up with mix. All the customer data in the world did not seem to matter for the 40 years. The point here is that thinking outside of the actual customer requests can result in some real neat stuff.

As for the idea “only good developers” don’t have a problem is some what miss-understood. This is really a very simple concept. I mean if I cannot come up with a better way of doing something then what the customer comes up with, then there really is not a problem here.  I have experienced a very wide degree of customers in this regard. Some are *very* precise in explaining what they want. Some are not.

To me, the real issue here is can you come up with a better way to doing things. Should we a developers *even* try to come up with a better way? As time progresses and I do have more projects under my belt, I find that more and more I am able to come up with a better process. I can not improve every request or idea. However, it does happen, and this seems to happen more often with good developers. A green developer with little business knowledge is going to have difficulty coming up with a better process. This idea seems to come across as arrogance. It is not. I hope this does not come across as preaching.

I also have argued very hard against the idea that customers can’t articulate what they want. I believe that they can and should be given more credit for being able to do so. As a good many have mentioned, this problem really lies with the developer. Lets not blame the customer here.

Lets ask the following question:

How come a developer can come up with a better way?

Virtually everything that customer does, from placement of their desk’s, placement of their phones, who they hire etc results in them creating their product. It is a no brainier that a customer wants to make hamburgers. The real issue is the *process* that they use to create that burger (or what ever product or service). While the customer may not think that where they place the photo copier is part of their business process,  in fact it is. Every burger place knows they want to make a burger. If they can’t figure out a decent process to do this then they probably will not be in business very long. Thus, everything that a business does is part of a process. This is where a good developer comes in. We developers *should* be more conscious of this “process” fact. This also explains why the common idea in this thread that customers can’t articulate what they want. Well, in fact their whole company is really based on a bunch of  process.

Thus, a good developer is really a process manager. There also one other large advantage that we as a developer:

We get to see more than *one* process in the company. It is *very* common that individuals in a company are working on a task (part of that larger process). These people tend to NOT to be aware of the other processes that happen *before* and *after* them. This is especially so as we as one goes farther up (or down) this process. It is this reason why we developers can often come up with a better way of doing things then can the customer. I have had *many* instances where the process are explained to me in perfect clarity. This process is thus the basis for what they want. However, that explanation was dead wrong! In other words, many companies are not aware of their actual business processes (hence, it is not that they are poor at explaining things...they really don’t know!). Since this happens so often, then it really means that the requests and thus what they ask for is really wrong. I had some instances where some mangers have told me that drawings are being done via a computer when in fact they where being done by hand! This also explains why some companies have difficulty explaining what they want. In fact, they are not really aware of their business process, and thus the requests they make to the developer will be flawed.

This is not to say that the customer is dumb. I don’t see it that way. We as developers have to figure out what the customer wants...since many a time what they ask for is wrong! They really do not know. Sad, but true.

I have *very* much enjoyed this topic. Mark, you have stimulated a ton of good ideas here. This subject has triggered enough thoughts and ideas for a book!

Albert D. Kallal
Tuesday, February 26, 2002

With all due respect, Albert, the mini-van was not custom-developed for one specific customer. The main point of Joel's article, stated repeatedly throughout, but most forcefully in the sixth paragraph, is that "on these CUSTOM PROJECTS the single most common cause of overruns, failures, and general miserableness always boils down to, basically, "the (insert expletive here) customer didn't know what they wanted?"

It's a pretty simple bottom line: consulting is not the same thing as developing. You can be a crack developer, smarter than anybody on the team, but unless you're able to effectively communicate with your customer (your very specific customer, who said "I want this thing"), then it's gonna be tough for you to be able to deliver value.

It's semantics, I know, but a "good developer" is most certainly NOT a "process manager." A good developer cranks out the best possible code. Period. A good consultant, on the other hand, wears a few more hats.

My issue with Joel's article, and the tone behind it, is that he also confuses development with consulting.

The great developer delivers exactly what the customer asks for, but not always what they wanted. The great consultant delivers what the customer wants, but not necessarily what they asked for.

Robert K. Brown
Tuesday, February 26, 2002

I'm not sure that the data that customers wanted a minivan existed for decades. I'm fairly sure the automobile industry operates on autopilot (pardon the pun) most of the time churning out the same type of vehicle over and and over again. The Station Wagon was the be all and end all family vehicle.

The real innovation may have been in the decision to conduct the study in the first place.

I agree that this article is about seeing *through* the customer's request to their actual need. I disagree that the programmer intuits the actual need through some magical mental gymnastics. It's a communication problem, plain and simple. I think communications errors come in one of a few basic flavors.

1. the customer makes an assumption about what the technology is or can do and designs their request around that.

So they give you a request that says "I want this button here, and this button here" but never explains to you their need.

2. the customer is just looking for a way to automate what *they* do.

So they give you a request that says "The program should recieve a fax, read it, print 3 copies, one for someone to file, one to be faxed back, and a third for the factory" when an online form attached to a database, and e-mail notification is what they really need.

3. the customer is "too close" to the process to understand any other way of chunking it up, or follow the process without understanding it.

This is just another spin on the above.

There are probably others, but these are the ones that come up most in my work. In both cases, it's a step back and an overview that's needed the most.

In the first case you need to say "forget about the technology, what is it you're trying to accomplish" and in the second case you have to say "ignore your current process, what is it you're trying to accomplish." A clear understanding of the beginning state and the end goal is important.

In a book I highly reccomend to anyone and everyone "Sources of Power: How People Make Decisions" by Gary Klein (which on amazon is somehow linked to "Don't Make Me Think" and some other web/usability book) he outlines "Considerations for Communicating Intent.

I don't have room to go in depth into them, but they're:

1. The purpose of the task (high level goals)
2. The objective of the task (a description of the outcome)
3. The sequence of steps in the plan.
4. The rationale for the plan. (why chose those steps)
5. Key decisions that may have to be made.
6. Antigoals (things you don't want to happen)
7. Constraints and other considerations.

I use this as a mental checklist whenever I'm doing requirements gathering. Most people focus on #3 without communicating any of the others. This is very similar to the rabbit in the monk story, and customer #3.

For example, a group wanted to put a document online. We were discussing the appropriate format when I interrupted and said "What is the purpose of this document? What is the end state?" This full-color brochure was to be printed and given to clients. Clearly the office printer wouldn't be the best solution.

Armed with the knowledge of what the end goal & purpose were (give document to clients, distribute globally) I suggested the post the Quark files instead of a PDF or Word Doc, and these could be taken to a local printer. They agreed.

This is a clear example of the customer "not knowing what they wanted" but it was through dialogue with the customer, not some sort of mental wizardry, that we came up with the solution.

Again, I'd like to stress that the customer does know what they want, but they're either too close to see clearly (type 2) or have misconceptions about the technology (type 1). These are communications problems, not stupidity on anyone's part, and magic on the part of the developer won't solve it.

This is equally a communication problem on the part of the developer. I don't want anyone to think that the customer is the only inarticulate one in the equation. Perhaps we're not clearly articulating what the stuff we're developing is properly used for. "We're really good at streamlining procesess, reducing errors due to manual entry (the customer enters, it's not transcribed from a hand-written form, we can do complex calculations reducing errors), and ensuring everyone gets the same information at the same time that they need it."

Just as the customer gets too close to the process to see the big picture, we get too close to the technology. Neither one of us is good at explaining what we want from the other. We never say "it would be really good if you gave us your requirements with these types of information" and somehow we blame them for giving us requirements without what we need.

Thankfully Joel & people like him are there to "help us help you" and make us examine our own processes & patterns closer.

On another note, it seems that the internet group at my job is being asked for higher an higher fidelity prototypes, and they suffer from the same problem of the business thinking that a high fidelity prototype means that it's done, and likes to quibble over things like "The page should have more red so it would look more dynamic."

Again, a communications problem waiting to happen. Any ideas on how to cleverly diffuse this? Joel's article has been well recieved by everyone there I've shown it too, but what do you do when they're explicetly asking for higher fidelity prototypes?

Mark W
Tuesday, February 26, 2002

"what do you do when they're explicetly asking for higher fidelity prototypes?"

Give them what they need, not what they want. Why are they asking for high fidelity prototypes? Have you asked them to define what a hi-fi prototype is anyway? If they say they want more "fidelity", maybe they really need a spec. Another option is that they want more frequent releases. They shouldn't want more functional prototypes if they know what's good for them.

B
Wednesday, February 27, 2002

"Fidelity" is a term my fellow workers use, I don't think it's a term the business uses. They're probably asking for a static website that they can click through to get a feel for what it will be like once all the functionality is in place.

So you would pretend to be Jane Doe logged in and seeing all of Jane Doe's information - this way they have something fancy to look at and show off.

Like I said, this isn't my problem, this is another team's, but I thought it might make for good discussion here and I'll share any insights I gain with them.

Mark W
Wednesday, February 27, 2002

I just attended an "intro to extreme programming" seminar the other day.  It was really well done, actually, and stimulated  my interest in learning more about XP.

The part that was relevant to this thread was the composition of the development team: the "roles" of customer, programmer, and coach are all absolutely required on each project.

It kind of blew my mind to imagine having a completely non-technical customer (marketing rep, QA person, etc) working with the programmers EVERY DAY.  But perhaps that would address some of these Iceberg issues, neh?

Can someone with experience in this aspect of XP please comment?

JIA
Thursday, February 28, 2002

> But perhaps that would address some of these Iceberg issues, neh?

Presumably iceberg issues exist more in some contexts (e.g. off-the-shelf shrinkwrap software, which you write speculatively for customers unknown) than in others (writing for a specific customer or customers, especially for technical customers, especially customers with whom you have long-term (multi-year) relationship, as for example the telco equipment vendors write for the telcos).

Christopher Wells
Thursday, February 28, 2002

*  Recent Topics

*  Fog Creek Home