Registered: Nov, 2002
Re: Flexibility and Complexity
Posted: Dec 2, 2002 4:50 PM
>This paragraph reminded me of Ken Arnold's discussion of >the arrogance of taste, which is on this page:
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.