 | ||
End user development video 1 introduction to end user development
End-user development (EUD) or end-user programming (EUP) refers to activities and tools that allow end-users – people who are not professional software developers – to program computers. People who are not professional developers can use EUD tools to create or modify software artifacts (descriptions of automated behavior) and complex data objects without significant knowledge of a programming language. Various approaches exist, and it is an active research topic within the field of computer science and human-computer interaction. Examples include spreadsheets, scripting languages (particularly in an office suite or art application), and programming by example.
Contents
- End user development video 1 introduction to end user development
- End user development video 2 three major pitfalls and three best practices
- Definition
- Examples
- Cost benefit modeling
- Criticism
- References
The most popular EUD tool is the spreadsheet. Due to their unrestricted nature, spreadsheets allow relatively un-sophisticated computer users to write programs that represent complex data models, while shielding them from the need to learn lower-level programming languages. Because of their common use in business, spreadsheet skills are among the most beneficial skills for a graduate employee to have, and are therefore the most commonly sought after In the United States of America alone, there are an estimated 13 million end user developers programming with spreadsheets
Early attempts in End-user development were centered on adding simple scripting programming languages to extend and adapt an existing application, such as an office suite.
More recent research tries to bring programming closer to the needs of end users. The Programming by example (PbE) approach reduces the need for the user to learn the abstractions of a classic programming language. The user instead introduces some examples of the desired results or operations that should be performed on the data, and the PbE system infers some abstractions corresponding to a program that produces this output, which the user can refine. New data may then be introduced to the automatically created program, and the user can correct any mistakes made by the program in order to improve its definition.
There are two basic reasons why EUD has become popular. One is because organizations are facing delays on projects and using EUD can effectively cut the time of completion on a project. The second reason is that software tools are more powerful and easier to use.
Lessons learned from EUD solutions can significantly influence the software life cycles for commercial software products, in-house intranet/extranet developments and enterprise application deployments.
End user development video 2 three major pitfalls and three best practices
Definition
Lieberman et al. propose the following definition:
End-User Development can be defined as a set of methods, techniques, and tools that allow users of software systems, who are acting as non-professional software developers, at some point to create, modify or extend a software artifact.
Artifacts defined by end users may be objects describing some automated behavior or control sequence, such as database requests or grammar rules, which can be described with programming paradigms such as programming by demonstration, programming with examples, visual programming, or macro generation. They can also be parameters that choose between alternative predefined behaviors of an application. Other artifacts of end-user development may also refer to the creation of user-generated content such as annotations, which may be or not computationally interpretable (i.e. can be processed by associated automated functions).
Examples
Examples of end-user development include the creation and modification of:
Cost-benefit modeling
According to Sutcliffe, EUD essentially outsources development effort to the end user. Because there is always some effort to learn an EUD tool, the users' motivation depends on their confidence that it will empower their work, save time on the job or raise productivity. In this model, the benefits to users are initially based on marketing, demonstrations and word-of-mouth. Once the technology is put into use, experience of actual benefits becomes the key motivator.
This study defines costs as the sum of:
The first and second costs are incurred once during acquisition, whereas the third and fourth are incurred every time an application is developed. Benefits (which may be perceived or actual) are seen as:
Criticism
Commentators have been concerned that end users do not understand how to test and secure their applications. Warren Harrison, a professor of computer science at Portland State University, wrote:
It’s simply unfathomable that we could expect security... from the vast majority of software applications out there when they’re written with little, if any, knowledge of generally accepted good practices such as specifying before coding, systematic testing, and so on.... How many X for Complete Idiots (where "X" is your favorite programming language) books are out there? I was initially amused by this trend, but recently I’ve become uneasy thinking about where these dabblers are applying their newfound knowledge.
This viewpoint assumes that all end users are equally naive when it comes to understanding software, although Pliskin and Shoval argue this is not the case, that sophisticated end users are capable of end-user development.
In response to this, the study of end-user software engineering has emerged. It is concerned with issues beyond end-user development, whereby end users become motivated to consider issues such as reusability, security and verifiability when developing their solutions.
An alternative scenario is that end users or their consultants employ declarative tools that support rigorous business and security rules at the expense of performance and scalability; tools created using EUD will typically have worse efficiency than those created with professional programming environments. Though separating functionality from efficiency is a valid separation of concerns, it can lead to a situation where end users will complete and document the requirements analysis and prototyping of the tool, without the involvement of business analysts. Thus, users will define the functions required before these experts have a chance to consider the limitations of a specific application or software framework. Senior management support for such end-user initiatives depends on their attitude to existing or potential vendor lock-in.