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
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
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 EndUser
s 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.
This has always been the case with Unix system administrators -- automating some of their tasks with scripts.
Some "office geek" EndUser
s 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 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.
In my experience there are EndUser
s 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.
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? ...
corrupting production data!)
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.
- "A Small Matter of Programming: Perspectives on End User Computing"