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