The Costs and Benefits of End-User Programming
How hard is it to give users the ability to program in your system?
That depends on how much programmability you plan to offer, and what methods
you intend to use. Adding preferences merely requires a GUI and some
dialogs enabling them to set parameters. However the degree
of "programming" you achieve this way is limited. On the other hand,
a thorough implementation of a scripting language may require:
Yet such a tool can let your users program a large and complex application
themselves. You get what you pay for.
an editor, preferably with at least syntactic assistance for the beginner,
an interpreter or compiler for your script language that links to application
an executive, possibly multitasking, for scripts to execute in conjunction
with your system,
error checking and debugging tools, and
documentation and version management tools.
Other approaches, such as visual programming (e.g. the "G" language
in National Instruments LabviewTM) or Programming by Demonstration
PBD, may be better for your users. Each has its own costs. For example
PBD has the smallest cognitive distance between programming and
working, because they are the same: you are literally "programming
in the user interface". Yet determining your intent in PBD may require
sophisticated inferencing and has a chance of error.
If you decide to pay the price and add significant programmability to
your system, there are additional costs to consider before you can start
to enjoy the payoff.
The bottom line: adding significant user programmability has
large and continuing costs that will shape your job as long as you support
Management and those currently responsible for the performance of your
product will fear the loss of control to users. "They'll screw it up, and
then we'll be blamed/have to clean up their mess." Deep-seated social divisions
and long-standing organizational traditions may lie between the group that
used to control the programming of your product, and the users who can
now join in.
The initial impact on documentation, training, and customer support will
be major. Your users may be slow to adopt the new tools, They probably
aren't used to programming, and they certainly aren't used to the tools
you are about to provide.
Some of the programs they produce will confuse them; others will do unintended
and damaging things, and at least initially some will blame you.
Regardless of their field, a certain proportion of your users will discover
a natural bent for programming. Expect them to push the limits of
the support they are offered, and find their way to the programming group
again and again with questions and requests. This interaction is
gratifying and very useful, but can be time-consuming.
If your tool is really useful, some user programs will be copied and passed
around by people unaware of their limitations and assumptions.
User programmers are even less prone than professionals to document their
productions, and programming is only a sideline for them. When a prolific
amateur moves on, she may leave quite a vacuum.
The next version of your program may have radically different features;
hardware and operating system sands may shift under you, but your users
will expect their programs to keep working.
If your users find the programming features you have added appropriate
and useful, the payback can be tremendous.
The bottom line: appropriate user programmability can transform
a system, multiplying the effectiveness of programmers and users alike.
Users know their problems best. The solutions they create for themselves
are rich with detailed features they wouldn't have time to specify or explain
to a programmer. A good tool allows many small experiments and becomes
part of a style of working (and system building) that is exploratory, iterative,
and highly productive.
Freedom begets responsibility. Once users get used to having control
over their system, they question themselves when there is a problem instead
of reflexively blaming "software." An engineer supporting a user-programmable
system told of the customer who demanded, "Stop babying me!"
That was a first in his 2 decades of customer support.
In a system designed around user programmability, the system program can
be orders of magnitude simpler and more reliable. Instead of maintaining
megabytes of specials for their whole customer base, programmers are set
free to build the general functions they are good at, while users create
the specific features they care intensely about. Both are happy!
There is a critical mass of functionality before end-user programming becomes
useful. However once it is reached, tools don't need to be fancy.
Serious users will work around missing features and push your tools into
applications you never dreamed of -- witness all the far-fetched applications
people found for spreadsheets.
The closet hackers who pestered the system developers while they were learning
later become a resource for other users; "Gurus" or "Gardeners" in the
terminology of A
Small Matter Of Programming.
Maintained by Howie Goodell