[
Lists Home |
Date Index |
Thread Index
]
> Developers complain about the tools all the time. Users do their best
> to avoid the tools completely, and I can't say I blame them. Very
> little of the work being done seems intended to help users
> communicate.
> I need to focus my own energies more squarely on this problem set.
Just be careful. Everytime I've been suckered into taking user requirements
literally, I've built systems that are fragile and unextensible. And then
the new requirements come in. "This is just a one shot deal, don't spend a
lot of effort on it." "Okay," I say. So I string something together using
Awk, sed, C, SGML, Postscript, and UNIX pipes. "This is great! We want to
make a permanent component!" they say, later. "We just need a few little
features." "I can't do that without rewriting everthing" I protest. "Why?"
"Because I slapped it together with bailing wire and bubblegum." "Well, why
did you do that?" "Because you told me--- doh! I shoulda known better..."
Suckered again.
And I've almost literally been told: "Build us a new system that fixes all
the problems in our old system, but make it work just like our old system."
Yeah, right. One of the biggest battles I had to fight against was the
perceived user need to enter duplicate primary keys for different data
records. These were, in the old system, resolved by context: if you picked
one id, and it showed the wrong information, the you did a 'find next' until
the right information (same id) came up on the screen. Sweet.
I also spent five years and countless 60-70 hr weeks helping develop a data
modeling system that was meant to be intuitive to users. It essentially
presented an objectified view of a relational database. It was very clever
and it worked pretty well (at least for simple cases), but there was one big
problem: most users, even given the right tools and a modicum of training,
build lousy data models.
An example. Our CEO decided to take one of our 'betas' out for a little
test drive. He built a little golf scorecard application (let's overlook
the practicality issues). What did he do? Well, of couse he created one
object for each hole, and each hole had the same properties: hole number,
par, player 1 score, player 2 score, .....
Except there was no use of groups or types (though they were available, and
explained in the walk-through tutorial). So each hole was basically unique.
Also, each player was unique: no use of array subscripting here! And, of
course, the resulting relational database had 18 tables, with 18 identical
column definitions.
Now, extend that to a real business case and I think you'll get my point.
Most users (not all) tend to see things 'flat' and 'unique'. They fail to
see hierarchies, relations, and types.
Could we have added wizards to the program to check for duplicate properties
amongs objects? Sure. Could we have added another to help spot candidate
hierarchies and natural array? Maybe.
Now, I could continue in another vein about my experiences of users not
really knowing their business, although they may perform their day-to-day
functions quite well. Teaser: they fail to have a complete conceptual
business framework within which to see the full ramifications of their
particular functional role. But I'll save that for another day...
I don't mean to discourage you, or to belittle the mental capacities of
end-users (who certainly do their jobs better than I could, even though I
tend to build them better tools than they could build themselves). It's
just that data analyst, business analyst, and business functionary each
bring to the table different skills and perspectives, and it's when they can
work well and closely together that the best systems are build. It all
boils down to teamwork.
|
