>I believe - using your analogy - your assumption that we are nutritionalists are wrong. We ARE caterers!

Dawie,

I agree with you that we are caterers. However, the point I was trying to make is that that could be the reason why there are so many half-baked software products out there. Catering to a bunch of confused users is not going to result in something coherent, to say the least.

So, the only way out of that mess would be to start billing ourselves as 'nutritionists', claiming that we're the people who know better than our users.

>If we were trying to solve technology problems alone, you would be right. We do know more about technology than our customers.
>BUT we are trying to solve business problems. And we don't know the customer's business - he does! So we listen to him and use our technology expertise to decide how to >give him exactly what he wants.

I would be in complete agreement with you if the customers would limit themselves to talk about business only. But the problem is, they tend to meddle too much with the technology side of the problem, and at the early stages too. The thing is, during many of the inception sessions I've had with my customers, they love to kick off by telling me how they need a database with such-and-such tables, and keys, and special codes. That's the first sign of trouble. For some reason, customers feel that we should speak the same language, and they often times bend over backwards to learn my 'lingo' and to talk the database crap, web pages and mouse clicks, even UML (believe it or not).

I am always on the watchout against such atrocious behavior. I always insist that we shouldn't allow any aspect of a computer-related terminology to enter our inception and elaboration phases. Only once we reach the design phase (meaning, we're past the requirements gathering and problem domain definition phase, even past the CRC cards and the use case scenarios phase), can we open up and start talking computer-related stuff.

So, if we can get to the point where we'll be talking strictly business with the customer, I absolutely agree that the customer should be 100% in the drivers seat. But then to translate these business requirements into the particular medium of technical implementation, we shouldn't allow the customer in. Let alone listen to his/her wishes.

Alex

> As Bill noted, the requirements gathering and high-level
> design process needs to be a conversation between the
> customer and the development team.
>
> But in the end, the customer is king when it comes to
> externally observable system behaviors. For all other
> behaviors, and for implementation costs, the development
> team knows best.
>
> Saying that the end user is not capable of describing
> desired externally observable behaviors is an
> extraordinarily arrogant attitude, and it is one that will
> be brutally punished in a capitalist marketplace.
>
> Nobody wants to pay your company huge amounts of money to
> employ ivory tower design practices to build software that
> makes you happy.


What we need to establish here is that there are three things involved:

1. Business requirements gathering

2. Formulating the requirements that are needed to define end-users' interaction with the system

3. Formulating requirements needed for implementing the system

Regarding the issue number 1, the development team has no business poking their heads in there. Business people can perfectly well gather their own requirements. In other words, they don't need us, nor do they need any technology in order to accomplish that.

Step number 3, on the other hand, does not require business people at all. We, the developers, can perfectly well gather our own requirements, and figure out how to implement the system in the most efficient manner. This is where methodologies such as XP have their say.

Step number 2, however, is tricky. This is where the 'externally observable system behaviors' are defined. And that's where we must be careful not to give in to what the 'king' (i.e. the customer) wants. The core problem here is that the customers have been conditioned by years of using lousy, inadequate systems. After being abused for such a long time, they grew thinking that it's the only possible way to go. Consequently, they'll always insist on having the least optimal solutions.

It is our duty here to step in and be adamant in insisting that there is a better way. We should take it on ourselves to calmly explain to the customer that they've been abused by the half-baked, incoherent products, and that they need to expect and demand more from engineered products. Instead of interpreting this as an 'extraordinarily arrogant attitude', as you say, they will most certainly appreciate our care. Evidence (in my case, ample evidence) has shown that not only is this not being brutally punished in a capitalist marketplace, it is being richly rewarded.

It all depends on your perspective, of course, but I am nevertheless adamant that we don't have to act subservient to our confused customers in order to gain their business and their respect. Customers will respect a very knowledgeable service provider who is exhibiting genuine care for customers' true needs.

Thinking otherwise exposes extraordinarily arrogant attitude, in my opinion.

Alex

Bill - all good points.
You are correct. Just because you can design for the future doesn't mean you have to. And you are correct again, it is a matter of 'extents'.

I would suggest that the extent would be based on the reusability of the platform. Creating applications that allow for reusability through neutralizers (OS, network, platform, language, location) incents one to create reusable code and thus consider designing for reuse. Service Oriented Architectures do this.

IMHO, we have a major shift in how applications will be written. My issue is that the gurus of OO seem to be stuck in OO-Land. When we talk about 'design' issues we must now preface them with an era (Structured, Object Oriented, Service Oriented) - because the rules have changed!
Jeff

>This paragraph reminded me of Ken Arnold's discussion of >the arrogance of taste, which is on this page:
>
>http://www.artima.com/intv/taste.html

I believe Ken is absolutely right, but I'm not sure why he put it in such lukewarm terms. In other words, things need to be spelled out more strongly.

For example, I disagree with his use of the 'painting the house' analogy. I think it's weak and doesn't serve the purpose well. A much better example would be building a house: yes, our customers may have all kinds of preferences when telling us how they want us to build their house, but there are many rock-bottom restrictions which no one's wish should be able to violate. I don't care if the customer promises to pay me extra $100,000.00, if the thing he's asking for is going to endanger the whole project, I'm going to decline him flatly.

I insist that we must adopt the same rigorous approach when designing a software product. Yes, the customers will quite likely demand foolish things from a product we're supposed to deliver, but we know better, and we should straighten them out as soon as the foolish demand arises. Some people may interpret that as being arrogant -- I interpret it as being a professional.

>What I find helpful is bringing all the parties together
>who have an opinion and want to feel included in defining
>the requirements, and get everybody talking about the
>requirements. I explore the requirements space together
>and help them figure out what they want. It is a process
>of exploration and negotiation between all the parties in
>the meeting. I do make suggestions and propose ideas, but
>for the most part the process feels like listening. After
>such a meeting I'll write down what I think we all agreed
>to and send it to everybody who attended the meeting.

I used to practise exactly the same apporach. Then one day I realized that it has the tendency to muddy the issue. What I do now is tell my customers not to involve me until they are absolutely certain what is it that they want to accomplish from the business point of view. That means, they should be able to sit down and hammer out their business requirements on their own, without having to involve computers/software at any point. I give them instructions to imagine they are dealing with the Alladin's magic lamp, so that whenever they feel they have a need for some sort of information service, they just put down something like: 'rub the lamp, the genie comes out, and we tell him what to do'. Everything else should be pure business, nothing to do with the genie, nothing to do with computers.

Then, once they are clear on that, I jump in and address the genie-related issues. I make an assessment as to whether the wishes expressed in there are reasonable, meaning whether the techno-genie can grant them or not. Most of the time, he can.

But *how* is techno-genie going to fulfill their wishes is really none of their business. They only worry about *what* is it they'd like to see as the outcome/externally perceived behavior of the system.

>My intuition is that it might make sense for developers to
>see themselves as nutritionists in the area of technology,
>but not in the area of the client's or employer's business.

Amen.

Alex