|From: [EMAIL PROTECTED]
|
|As important as the technical factors may affect performance of end-user
|programming, they may be dominated by contextual factors.
|End-users are, by most definitions, people who are primarily view a
|computer as a tool to be used to accomplish a goal. A computer is just
|another piece of equipment that they operate. From this perspective, end
|user programming, even if done successfully, may have undesirable
|consequences:
|
|[1] Customizing your software may mean that you get to do more of things
|you don't like to do. In many environments, performing a task well means
|that you get to do more of it. If you customize your software so that you
|are faster/more efficient than other people at a task, you will probably
|get assigned to do that task more often. If you customized you software so
|that a task took less of your time, this is probably not what you wanted to
|happen. This extends to the customization activity itself; if you're good
|at it, other people will regard you as selfish and cruel if you don't help
|them.
I don't buy this. We were talking about professionals, like doctors
and lawyers, doing end user programming. At those levels, I don't
think its "competence is it's own punishment". People have a higher
level goal to accomplish, and if customization would make it easier to
get the goal done(in the larger context -- keeping in mind the cost of
doing the customization), they will do it. Your concerns might apply
to a clerk who customizes her workstation, but even there, I'm not
convinced. If the customizing makes it possible to eliminate a boring
part of the job and frees you up for the more fun parts, even people
who work by the hour rather than until the job is done may be
motivated.
If you think of customizing as personalizing, I think that people
will do lots of it, if it is easy enough. Look at the time people
spend arranging their color schemes and wallpaper on pcs. But it's
got to be easy. I think that there is a "time value of effort"
metric that people use, and upfront time has to pay back very highly
if it is to be perceived as compensating for small amounts of
extra time on each cycle.
|[2] Customizing your software may mean that you get less help when you have
|problems.
I certainly agree with this point, and I wonder how we will be
able to solve it. Customizable software, especially software that
is so customizable that we would call it end-user programmable,
makes the set of states that you should test for infinite. And
it's extremely hard for tech support to figure out how to
configure a machine so that it matches the user's configuration,
so that the problem state can be tested for ad hoc. Finding
the problem before the product ships, reproducing the problem
once it occurs, and finding a fix that doesn't break something
else are all huge problems once software becomes that flexible.
|[3] Interest in customizing your software may be viewed as lack of interest
|in other, more important aspects of your job. Even if the results of the
|customization save far more time than they cost, the question may get
|asked, why didn't you spend as much effort in improving the more important
|aspects of your job.
|
|Ruven Brooks
|
I'm not completely persuaded by this point. It may be true in
some cases, but not always (I live in Silicon Valley, where being
at the forefront of technology is often valued even if it costs
you more than it saves, so I see the opposite more often than this).
But if it is true, it's a short term issue, that will go away when
we have case studies of the huge advantages of end user programming.
(or should I say "if"?)
Robin Jeffries
