Can End Users Script

See SeriousVersusScriptingLanguages, ScriptingLanguage, AlternateHardAndSoftLayers, PythonLanguage, PythonProblems etc

These scripting discussions are great but one big question remains for me: where does the EndUser fit into the scripting picture ? As I see it this misunderstood cry baby (cf BizarroExtremeProgramming) is getting on with it without us, producing vast volumes of unmaintainable VBA as we speak.

I deliberately took scripting and began to associate it with end user in all my presentations on the future of software a few years back - around the time that I gave up on Smalltalk ever being considered a mainstream, serious language (as alluded to in RichardDrake).

As I saw it, big M and Netscrape had already done the same thing, in effect, for very different reasons. I'm not sure that professional developers have yet thought through the implications of this kind of scripting (the Office/Excel/VBA kind even more than the HTML/JavaScript kind) and how if at all it relates our old style shell scripting, whether in the kshell, rexx or VMS command language.

I happen to believe that this EndUser trend spells opportunity for the kind of dynamic, untyped languages some of us have come to know and love ... and needs to be accommodated in our new XP-style development processes.

What are the implications if EndUsers can script? Or is this confusing two entirely separate phenomena?

In my experience, writing scripts is still a specialized occupation. But not as specialized as with "serious" languages.

What I've observed is an increasing number of "casual programmers," who write script programs as part of some other job. ("part-time programmers"?) This has always been the case with Unix system administrators -- automating some of their tasks with scripts. Some "office geek" EndUsers have also been known to write Excel macros and to learn SQL. They often use these skills to help their non-technical coworkers, or to write reports for their boss. But what may be most interesting is a new class of programmers who build systems full time, but use only pre-built controls, wizards, and simple scripting languages. Like, for example, some web site designers.

I do not criticize these people as being "lower class" than C++ specialists like myself. They aren't: They are using the most appropriate tools available for the job. (...something I try to do, whenever I am able. ;-)

I would certainly like to encourage giving your users (and coworkers) as much control and power in their environment as possible. Yes, there are risks that they will "mess things up." But it's their business: It's better to give them the power to achieve great things than smother them with safety -- stifling their success. -- JeffGrigg

In my experience there are EndUsers who can write workable applications that will run whilst they remain around. As soon as they move on, us real programmers are asked to support these applications. Often there has been no use of standards, naming conventions or documentation to support the application and we end up having to re-write the application from scratch - just so that we can maintain it in the future. The only way End-Users should be able to write code is with the support of a real programming group to assist in developing the application into a sustainable form utilising standards & naming conventions and assisting in the design process to make sure that the final result will work reliably. -- SimonMedley

If they check it into SourceSafe, and the code gets tested and a revision history is kept, I say let all end users script. CadeRoux

Conversely, if the scripting system provides an appropriate limit (e.g. sandbox) beyond which the naive user can not shoot himself in the foot in any meaningful way, then I would not be adverse to the users maintaining their own utilities. I'll say that again, maintaining their own utilities - once it enters the realm of an expectation of developer (professional) support - then it falls into the revision control/lifecycle model (agile/iterative or otherwise). -- MalcolmCampbell

Data driven systems and processes scripted under user control give the business users the power to achieve great business results. But, in most systems I've observed, there is entirely inadequate testing and revision control of user-controlled metadata and scripts. In fact, I've seen situations where the desire to avoid revision control seemed to be the primary motivation behind demanding that business logic be in user changeable scripts.

Be aware of the issue: When designing data-driven or scripting enabled systems, ask how the people maintaining this data will test their work before it impacts production data. How will they recover in the event of an error? (In most cases, you won't like the answers. ;-)

(Here's a related training issue: How will new people be trained to use the system? ... without corrupting production data!) -- JeffGrigg

Someone recommended a book to me years ago on this subject. I have it on my shelf, but I haven't had a chance to read it yet.

ISBN 0262140535 - "A Small Matter of Programming: Perspectives on End User Computing"