The Costs and Benefits of End-User Programming

The Costs:

• an editor, preferably with at least syntactic assistance for the beginner,
• an interpreter or compiler for your script language that links to application functions,
• 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 Labview^TM) 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.

• 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.

The Benefits:

• 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.