Re: Another Perspective on the Cause of the Keyhole Problem
"Balog Pal" <[email protected]> Tue, 4 Nov 2003 08:10:02 +0100
| Newsgroups | gmane.comp.programming.keyholes |
|---|---|
| Message-ID | <000201c3a2a9$a3828ac0$65bf9f81@bpnt> |
> I could see retaining the "control" argument if it To me it looks like a mere rethoric problem. What about scrapping "control" and replace it with "freedom". ;-) One will likely not fight to lose his control and grant it to others, but we do fight for freedom of other people. Especially if it's put out clear enough they want it. (anyone watched Amistad? ;) What about organizing the book to show two distinct perspectives? Systematically. The chapter has two parts, one tells the story from the user's perspective, the other from the developer's perspective. The first like use cases -- with painful, problematic runs on use. I recon many of the problems in SW development comes from here, lack of system designers, and development concentrates NOT on use cases, not on understanding the user's problems and view. But on "solutions", on what some API, tool, system, etc provides. Well, when schedule is tight t may be the only way, but many things could be straightened later, in the next iteration. And they arent, the implementation picked first gets locked in. *and an important part of that lock-in happens on mental level* not on technical level. Just as in XP, it worth going for the simplest soultion that could possibly work (say, use whatever stock listbox is there). Here it is the developer's problem, and the goal is merely "allow to chose one of N options". That is well acomplished, choice is possible, and always get one pick, always from that set. Case closed, no further thinking required. Ever. User feedback will sure arrive if the program has a bug, something not works, or complete features are missing. But when something can be done, just doing it is cumbersome -- that's likely not trigger a feedback. For a ton of psychological reasons. Thus presenting the programmers the user's view, the common painful points, and so on -- has a great value. Beaming light to the dark corner. I'm sure it can be done in a way that a developer will conclude 'yeah, it really is painful, I can do it better, and it worth the effort." Paul