Fog Creek Software
Discussion Board

Thoughts on CAMEL?

Evry time I read the CAMEL saga ( ), it is unclear to me just exactly why the current system is being replaced.
Seems there are two tracks running in paralell:
a> Here is the current system. It does "Open Case". "Edit Case" "Search" - not a lot, but hey, just give us the (input more modern tech/architecture) clone of this ugly duckling by October 2003 so we can ditch the VT100's.
b> This current system is not what they truly need, it is far too limited and does not even seem to reflect cases are realy treated. We need to start doing field research. Early investigation has already produced this 178 pages document of things that could be truly usefull in case management (well, there are a few political snags, so the users might never want to install this system). October 2003? You must be joking right? This is a full blown Client/Server state of the art system. No way. Let's aim for a rough spec by the end of September.

Maybe a bit harsh, but I have seen these things happen. Are you trying to go for the S-Class Merc when the deal was closed on a Geo Metro?

P.S. Philo, could you do full content in your RSS feed, please?

Just me (Sir to you)
Monday, April 7, 2003

This raises an interesting issue about professional responsibility.

For example, If I call in a builder and deman he knocks down asupporting wall, then the builder isn't going to do it.  He's going to tell me I need to do this and that to stop the house falling down.  I can demand that he just knocks in the wall and tell him I'm not going to pay any extra, in which case the proffessional builder will walk away.

Of course, I can always get some cowboy builder in to wreck my house, and pay the penalty.

So is it similar for developers.  If a user is demanding a system that is clearly not fit for purpose, is it our duty to either do it right or walk away, or is the customer always right?

Ged Byrne
Monday, April 7, 2003


I see where you are getting at, but we are not talking destruction and mayhem here.
If you want  a building analogy it is maybe more like getting someone in to repaint the kitchen over the weekend, and then he not only wants to get in all new appliances, but also completely redo the ground floor, including major construction works and landscape the garden. Of course, no way can this be a weekend job. Well, you said you wanted "more light in the kitchen to make cooking more joyfull", rigth?

Just me (Sir to you)
Monday, April 7, 2003

I see it as a good developers responsibility to correct the customer if he is obviously wrong. Some consulting companies I have seen will gladly tear down the supporting wall; and then be happy to rebuild it, with the motivation "at least we get paid".

This acceptance of doing what you know is wrong, and then do it right again is the worst unprofessionalism I have seen. Needless to say, I have seen it only in this industry.

Makes me wonder if its really a market-maturity issue. I mean I have met numerous customers that were professionals in other areas, who seriously believed they could outperform real developers and write the system themselves.

Remember once when I was working in a booth at a tradeshow where we were giving demos of our product. It was not a huge product, but it had maybe 4-5 man years on it, it was a Windows client/Oracle database application.

One guy that had the demo said:

"Oh..this is very easy to do yourself in Access". My reply came without missing a heartbeat, "Well, sir, then I suggest you go do it."

Probably the smartest thing I said all trade-show :-)

Most customers wants to solve a business problem. Thats what they should care about. But it is also considered OK to question the developers on how to implement the code. Use this technique, use that algorithm and so forth.

As I said, I think its a maturity problem that hopefully will go away as the market matures.

Maybe they question the Boeing 767 captain on how to fly his aircraft on their vaccation trips also. Who am I to know?

Monday, April 7, 2003

Excuse my previous rant;

When thinking about it a little more, I think the problem lies in the problem programming (especially custom programming) is not considered expertise or professional services by some.

Three years ago everybody and his brother claimed to be programmers, and that probably led to the common belief among non-programmers that everybody could be one. Its just a matter of learning the correct three-letter-acronyms.

When I have heard "the-customer-is-always-right" bitch sessions it has always been aimed at low level service staff, by that i mean cashiers, mc-donalds employees, taxi drivers and also programmers, but I have never heard of somebody bitching at their doctor for being denied a requested type of medication or whatever.

To get rid of this we need to come across as trained professionals; It should be obvious to the customers that we provide a high level of service, and we will get away from this problem I think.

Easier said than done :-)

Monday, April 7, 2003

Just me -
On the kitchen analogy, I see it this way:
Building manager calls you (building contractor) to "redo" the kitchens in his apartment building, because they're 18 years old and the tenants don't like them. You look at the kitchens, and they have an icebox, hand-pumped sink, and coal stove.  No counters or cabinets. Floors are bare wood. Most tenants keep their food in the hallway closet.

You ask the building manager what his goal is - does he want to just replace the appliances, or does he want his tenants to be happy so they stay in his building.

"I want the tenants to be happy." He says. So you ask to interview some of them to see what they want.

"No time for that," he says, "a lot of them are threatening to move out if I don't redo the kitchens, so just redo them."

You draw up a plan for a modest kitchen with inexpensive refrigerator, electric range, and sink. You also put in cabinets, linoleum, and some counter space. You find a good nook to put a pantry in. All the designs are with "contractor quality" materials - no extravagance whatsoever, you just design a standard kitchen like you'd see in an average building development.

Of course you tell the manager that it'll take about ten months, and it'll cost more, but you feel that's the bare minimum you can do.

The manager screams at you and yells "all they need are a new fridge, oven, and sink! What are you doing with all this 'counter' stuff? They're gonna leave soon if I don't give them a good kitchen!!!"

That about sums up what's going on here...


Monday, April 7, 2003

Best of luck Philo,

sure hope you are not on a fixed price contract (with penalties for late delivery?). Also be carefull to stay well out of range of any "bait and switch" charges. I feel you are doing ths with the best intentions, but let's be carefull out there.

Just me (Sir to you)
Monday, April 7, 2003


I hope you've got a sense of humor about this (and it seems you do).

Question -- and maybe I'm taking a presumptious and preliminary pessimistic position[1] -- what are you doing to cover your and your team's butts when this project goes over-schedule/budget?


[1] Didn't plan that alliteration, it just happened....

Monday, April 7, 2003

Have you thought about explaining them the situation using this analogy ? If you are lucky they aren't totally  Dilberted.

Application Specialist
Monday, April 7, 2003

You are giving the customer what you want. Sounds professional

Monday, April 7, 2003

To the last nameless comment - "You are giving the customer what you want"

No. We have offered many solutions. We have asked "do you want to simply replace the existing system with similar functionality?"
"No, we want all this stuff too"
At one point in one project meeting I flat out asked "look, do you want us to just code data entry templates that replicated the existing system exactly? We can do that, and we'll be done by October 1"
The manager there looked startled and said "no, that's not what we want"

What they want is they want it all - they want fast, cheap, AND good. And they will not decide which one to get rid of.

Those who have been there for a while say the best course is to plan on Good and move forward. When it finally becomes apparent that Fast isn't gonna happen, then the management will just cave and adjust their schedule.

You wanna talk unprofessional? THAT I ain't gonna do. Three of us are standing on the tracks waving flags, shooting off flares, blowing horns...

...and being completely ignored...


Monday, April 7, 2003


just a question: does your solution just drop the "fast" part from the equation, or is the "cheap" part also in jeopardy?

Just me (Sir to you)
Tuesday, April 8, 2003


Could you persuade them to take an XP approach?

In the first iteration, implement the existing system as is.  The first iteration can be over for October 1st.

Then the other stuff can be added in itterations 2+ (if that ever happens)

Ged Byrne
Tuesday, April 8, 2003

"Just me" - to be honest, I can't get a handle on "cheap" because I simply cannot get a read on what they want.

I already know overtime isn't a problem, so I just don't know.


Tuesday, April 8, 2003

If I were heading up this project, here's what I'd say:

If you had to pick one of these two options, which would you prefer to have?

1. A clone of the existing system by October, and then make changes from there

2. A solid design for a new system by October, and then implement it.

And any response that is not a valid option, would receive this reply from me in turn: "That would be great, but what I asked was *If you had to pick one of these two*."

Once you have your answer, simply act on it.  I've occasionally had to explain further than that, i.e. to explain that those really are the only options, etc.  But ordinarily in cases like this, "Clearest Vision Wins" is the rule.  If you are more clear about what you want, than what they are about they want, then your vision wins: just act as though you know what you're doing and are the authority on the matter.

Phillip J. Eby
Wednesday, April 9, 2003

*  Recent Topics

*  Fog Creek Home