'End-user programming' is a term that has been introduced to me by the editor of the IEEE magazine SOFTWARE in his column, "The dangers of end-user programming" (July / August 2004).  Warren Harrison defines end-user programmers as "mechanical engineers, doctors, physicists, teachers, and accountants.  They are marketing assistants, receptionists or commodity brokers.  They are, in short, individuals who taught themselves to program."  The idea of having 'end-users' -- people with no background in software testing or development -- directly manipulate software that is critical for a company frightens the software professional.  Harrison's conclusion is that end-user programming is a threat for mission-critical systems from the perspective of both correctness and security, and he asks himself:

"Can it be true that software manipulating my credit history could have been written by an accountant with no concept of software testing or development processes?"

What is the motivation for end-users to get involved in software development?  After all, end-users are educated for a different subject matter; they did not choose an education as programmer, so why would they start building a system, investing so much (free) time in learning how to code in Microsoft Excel, Access, or Visual Basic, and overcome all the barriers involved with end-user programming?

These programs are born out of a need:  a businessperson has some particular knowledge that he wants to re-use, automate, or share with colleagues.  IT departments seem not to be able to accommodate such needs for reasons that are unclear.  When IT does build an application to accommodate the needs of the business, all rules (knowledge) are hard-coded in the programs, business people are not able to inspect the rules, and changes to the business rules take a very long time. 

The business rules approach offers a range of methods and techniques to improve the collaboration between IT departments and business departments.  A business rules management environment targeted at end-users is a better idea than end-user programming because this environment should limit the options of an end-user to only change rules, while security aspects, for example, are handled by the business rules management environment.  But there is much more needed to succeed.

Given the facts that regular software development environments do not have specialized support for verification and validation of business rules and that communication between business and IT often involves misunderstanding, I observe:

With proper support for verification and validation of business rules in a business rules maintenance environment, the correctness of software with respect to business rules will improve rather than be threatened.  The time we gain with serious end-user programming, supported with a good business rules maintenance environment, can be spent by software professionals on the security and stability of the systems supporting the rules of the business.  The business rules approach offers a viable approach to support end-user programming.

# # #