1
End-User Software Engineering
Andrew Robert Rosene
Department of Software Engineer
University of Wisconsin-Platteville
Abstract
End-User Software Engineering is an activity that has been around for a while and its usage has been continually growing. Despite being employed so frequently by so many, it is also a very misunderstood and stereotyped activity. It is this misunderstanding coupled with the constant usage growth that has triggered much research into understanding not only what End-User Software Engineering is, but also how it can be improved using the techniques employed by Professional Software Engineers. This paper will correctly define End-User Software Engineering, highlight ways in which this activity is similar to and different from Professional Software Engineering, discuss the importance of the continual research of this activity, and lastly analyze some of the more popular tools that aid in the process ofthis activity.
What is End-User Software Engineering?
Despite being used on a daily basis it is still commonly misunderstood. Therefore, it is necessary to establish a uniform understanding of what is meant by the term End-User Software Engineering. However, to do this it is important that three other terms be understood as well, in terms of their use in this paper. To begin, the definition of a program must be discussed.
Program
There are many definitions and conceptions about what a program truly is. According to Dictionary.com a program is “the precise sequence of instructions enabling a computer to solve a problem” [14].This does an excellent job of describing a subset of programs, most specifically macros and other scripts. However, it doesn’t really apply to all types of programs. Yet another definition for program, according to the Computer Dictionary, is “a single, complete and more-or-less self-contained list of instructions, often stored in a single file” [16].However, this definition assumes too much; primarily the assumption that a program is always complete. This can’t possibly be true (what makes a program complete?). As shown, a definition of a program that is vague enough to encompass all types but descriptive enough to exclude what isn’t a program is a tricky task. The definition that will be used throughout this paper says that a program is “a collection of specifications that may take variable inputs and that can be executed (or interpreted by a device with computational capabilities” [5].
Software Engineering
To properly define End-User Software Engineering it is important that we also define Software Engineering. This will also be useful throughout the remainder of this paper, largely due to the comparisons that will be made in the upcoming sections. As with all of the preceding words, there are many definitions for Software Engineering. Therefore, the definition that we will be using is that of the IEEE (the Institute of Electrical and Electronics Engineers) which defines Software Engineering as “the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software” [3].
End-User Programming
To fully define this term it is important to first understand the definition of an end-user. To be concise, an end-user is anyone who uses a computer [5]. When we refer to end-user programming it is, in general, programming done by anyone using a computer. This however, is not a very descriptive definition. Therefore, when we say end-user programming what we mean is “programming to achieve the result of a program primarily for personal, rather [than] public use” [5].
End-User Software Engineering (EUSE)
Having now defined all of the other necessary terms we have all of the pieces to define the major term for this paper. The only way to properly define End-User Software Engineering is to note it is a form of Software Engineering; because of this, end-user programmers face many of the same software engineering challenges. However, there are many differences that clearly separate EUSE from Professional Software Engineering and to fully understand what end-user software engineering is it is essential to understand these differences.’
The main difference between professional programmers and end-user programmers istheir goals: professionals are seeking payment for developing and maintaining programs over time; end-users, in contrast, are focused on developing programs that support some goal that exists in their domains of expertise [5].Therefore, it is obvious that many different people participating in programming fall under the category of end-user programmers. Secretaries, accountants, children [13], teachers [18], interaction designers [9], scientists [15], or any person writing programs to support their own personal goals fall under the classification of end-user programmers [5].Even expert programmers can fall under this category as long as the programming is being done with the intent of accomplishing a personal goal.
Comparison to Professional Software Engineering
As discussed in the previous section the difference between End-User Software Engineering and Professional SE is the intent behind the programming being done.In EUSE the intent of the programming is to achieve a personal goal (e.g. writing macros to automate repetitive tasks). In Professional SE the intent of the programming is to achieve a public goal (non-personal). This difference in intent is the cause of the key difference between professional and end-user software engineering, “the amount of attention given to software quality concerns” [5].
The differences in intent and attention to quality are not the only differences between these two activities. Therefore, to fully understand EUSE it is important to discuss these differences. Examining the reasoning that drives the actions taken during different phases of the software development lifecycle is the best way to highlight the major differences and similarities. The areas that will be examined are: requirements gathering, design and specification, testing and verification, debugging, and maintenance.
Requirements Gathering
If you ask any Professional Software Engineer they will quickly tell you exactly why gathering requirements is crucial to the success of the program. If the requirements are not thorough it is almost impossible to build not only the right program, but to build the program right. Therefore, tons of time is spent in the requirements gathering phase before even beginning any programming, usually. However, for end-user software engineering, having formal requirements, or requirements in general, is often seen as unnecessary. This difference between professional and end-user software engineering is due to the difference in the source of the requirements [5].
For professional software engineers the requirements come from the customers and users of the program, generally not the engineers themselves. This is not true for end-user programmers. End-user programmers generally program for themselves, a friend, or a colleague [5]. It is this difference that leads to the difference in importance placed on requirements gathering. The end-user is the customer/user and therefore is programming to achieve a personal goal, not programming to fulfill someone else’s. Therefore, “[f]or end users, the requirements are both more easily understood (because they are their own) and more likely to change” [5].
Design and Specification
The next area of development we will examine is design and design specification. In software engineering, the purpose of design specifications is to specify the systems internal behavior [5]. The design specifications are used to lay out the implementation strategy for ensuring that the system meets all of the requirements. This is done by assigning appropriate priorities to each requirement so that the highest priority requirements are taken care of before the low priority ones.
In end-user programming, it is often a struggle for the end-user to translate their requirements into a working program [5]. This is due to the fact that end-user programmers generally don’t have training or experience in design and therefore see little to no benefit to it [5].However, instead of design specifications, end-user programmers’ often come to realize what constraints exist on their programs’ implementations through the process of writing their program [2].
Testing and Verification
In professional software engineering testing is an essential part of the software development lifecycle. Testing is the way in which software engineers ensure the proper execution of the program. This is done through the use of many different testing techniques such as JUnit testing, regression testing, embedded test cases, etc. It is by running these tests that software engineers are able to identify bugs and properly debug the code, which will be discussed in the next section.
The primary difference between EUSE and professional SE is that the priorities’ of the end-user programmer frequently lead to overconfidence in their programs correctness [5].It is known that professional programmers are overconfident [8][17][7], but as they gain experience this overconfidence subsides [6].In comparison, many studies about spreadsheets report that in spite of high error rates in spreadsheets, the developers of the spreadsheets are carelessly confident about its correctness [11][4].
Debugging
In professional software engineering, debugging is an essential activity to ensure that the programs requirements are being met. Debugging is different from testing and verification in that instead of being used for the detection of errors, debugging is the means by which errors are found and removed from the program [5]. This activity is one of the most time consuming activities undergone to ensure that the program meets all of the requirements. This is because debugging requires that the programmer has an excellent understanding of the program, and is able to identify areas that could have caused the problem.
The primary difference between end-user programmers and professional software engineers is that, unlike professional SE, end-user programmers often lack accurate knowledge and understanding about their programs execution [5]. Because of this,it is very hard for many end-user programmers to even conceive what the root-cause could be, and even harder for them to actually be able to remedy the bug. Furthermore, because end users frequently prioritize their external goals over software reliability, they often rely on debugging strategies such as making code changes until it appears to work as expected [5].This approach often leads to the introduction of additional errors in the code and the original functionality can be lost.
Why Research End-User Software Engineering?
With the increase in the number of end-users using EUSE to achieve personal goals comes an increase in the risk of an error resulting from lacking quality procedures, as described in the above section. It may seem hard to believe that a bug in a single end-user’s program could be that big of a deal. However, it is this very reason that researching ways in which the quality procedures can be integrated into the processes of end-user program development is so important. To illustrate the importance of this let’s examine the following scenario.
Assume the end-user we are examining is an employee at a big bank firm whose responsibility on a daily basis is to remove entries from the bank’s MySQL database that reference loans that have been sold to other banks. Noticing that all of the records that need to be removed have two things in common he begins to explore possible ways in which this process can be automated. After scouring the internet this particular user discovers a bit of code that, based on the attached documentation appears to be able to complete the goal, with only slight modification.
Figure 1: Coding sample before editing
Figure 2: Coding sample after editing
As you can see above, Figure 1 contains the code example the end-user found while Figure 2 is the code after the modifications. Being unfamiliar with MySQL the end-user doesn’t realize that the semicolons at the end of the lines were simply aesthetic and that for the command the only semicolon should be at the end of the command. Also being unaware of the danger that running this command holds, the end-user runs the command without testing it. Despite being a wrong command, the first line is an actual command and executes deleting all records in the loans table.
This example may seem a bit exaggerated; but, on the contrary, this is not an unlikely scenario. Something similar to this occurred in Texas when an oil and gas company lost millions of dollars due to an error in a spreadsheet [10]. Sadly, this incident could have been averted if the end-user had been aware of the benefits of testing. Proper testing would have identified that the script was in a malformed state and would result in only the first line executing, dropping all records from the table.
It is because of scenarios like those mentioned above that motivate the need for further research into methods of introducing software quality principles used by professional software engineers into end-user software engineering. By studying the tendencies of end-user programmers it has been possible to come up with several tools that help end-user programmers create programs to meet their own personal goals while at the same time providingdebugging features.
Popular Tools that aid in End-User Software Engineering
There are many tools available whose main purpose is integrating software quality principles used by professional software engineers into end-user software engineering. Because the vast majority of end-user programming is done through the creation of spreadsheets, the majority of the tools below are aimed at debugging in spreadsheets.The tools that will be discussed are Topes, What You See Is What You Test (WYSIWYT), and Whyline.
Topes
Topes is a model and supporting system with the purpose of supporting validation and reuse of small, human-readable data in programs created by end-user programmers’ [1]. More specifically, users define string-based data types which can then be used to verify the validity of both data and operations in programming languages that store information as strings [5]. By supporting the design of custom data types, end-user programmers are able to easily process and validate information [5].
What You See Is What You Test (WYSIWYT)
The purpose of What You See Is What You Test is to help users test their spreadsheets while they are in the process of creating them. As the user develops a spreadsheet, they can also test the spreadsheet in an incremental and systematic fashion. At any point in the development process of the spreadsheet, the end-user can validate any value that he/she observes to be accurate [1].Each validation done by the end-user is processed, in the background, and used to measure the quality of the testing being done in terms of a test adequacy criterion that is based on data dependencies [5]. The measurements are then projected to the user by means of several different visual devices to assist in directing their testing activities [5].
Whyline
Another useful tool for ensuring the implementation of software quality practices in end-user software engineering projects is a tool called Whyline. Whyline is a debugging tool that allows the end-user programmer to ask questions of the type “Why did” and “Why didn’t” regarding the outputs generated by their program. The program chooses from a set of questions that are automatically generated by Whyline through the use of static and dynamic analyses, and Whyline is then able to provide different answers in terms of the runtime events that could have caused or prevented the desired result [1].
Whyline was originally prototyped in the Alice Programming environment and results of studies done measuring the amount of time users spent debugging using Whyline compared to those who did not use Whyline produced startling results. End-user programmers using Whyline where able to debug the same bug as end-user programmers not using Whyline in one eighth of the time [1]. Based on the results of this study it is not only clear that this tool has profound benefits to the end-user programmer, but that the benefits are in the form of higher software quality.
Conclusion
With the number of end-users participating in end-user software engineering continuing to rapidly increase it is becoming increasingly important that end-users not only be aware of the risks associated with EUSE but also be aware of the tools like the ones listed above. With an increase in the number of users that are participating comes an increase in the chances that one of them will fall victim to an unfortunate incident like that of the oil company mentioned above.To help in the prevention of future multi-million dollar errors it is imperative that research continue on the subject of EUSE. The better we understand the reasons that drive people to program the better we can gear software development tools such as the ones mention above to end-user development thus reducing risk of error during development.