Introduction

The proliferation of PC-based computers in the work environment, and the realized utility they can provide, has spawned the growing need for "small-scale" software application development. Traditional software engineering has sometimes dismissed these "small" projects as not being worthy of serious attention, but such projects increasingly make up the bread and butter of many developers' responsibility (McConnell, 1997). A "1 x 3" project, whereas one developer works for 3 months to complete the application, may not be a business mission-critical commodity but end-users of these applications still expect to receive a usable, reliable, quality software product. Many of these applications are built using fourth generation language (4GL) development environments (i.e. Visual Basic, Delphi, PowerBuilder) that allow applications developers to quickly produce GUI-based applications such as database information systems, task/domain-specific applications, and client/server based software (Harrison et. al., 1995; Komiya, 1993). The application development is usually done in close proximity or coordination with the ultimate end user(s) of the application.

Importance of the Problem

Considered by many as prototyping tools within traditional systems development, 4GL tools are used to build powerful "prototype-to-production" interactive applications by solitary individual developers or small teams. However, in a solitary development environment, the quality of the application is dependent upon the skill of the individual programmer (Constantine, 1995; McConnell, 1997; Millington & Stapleton, 1995). Quite often, one programmer will design and develop the entire application, which tends to propagate the "hacker" syndrome (Humphrey, 1997).

This literature review will concentrate in two main areas: the problems and issues faced by solitary developers working small-scale projects, and the use and problems of 4GL "production" tools in this development environment. It will present the solitary applications developer in a holistic manner, and discuss the issues and problems of this ever expanding group of computer professionals. It is assumed that the solitary application developer has obtained at least a computer science undergraduate degree, and is working in a professional or business-oriented environment.

Current State of the Art of Solitary Software Development

The Person

In an in-house development environment, one applications developer (4GL programmer) may wear "all of the hats" in the development lifecycle of an application (i.e. design, code, test, document), as well as provide the training and possibly the maintenance of the application after its deployment. Projects fall into the executive information systems (EIS), decision support system (DSS), or operational areas of automation. A one-person project rarely produces a "mission-critical" system in which life or limb, or the business itself, is dependent upon! Nevertheless, the investment of time and money into development of an application that benefits the business validates the assumption that the application is truly worthwhile and important. The analysis, design and development of these projects are beyond the capabilities of most end users, so they do not fall into the "end user computing" bucket of applications development. On the other hand, such projects do not typically warrant the involvement or control of the traditional management information systems (MIS) shop.

Unfortunately, many graduates of a traditional computer science curriculum are unprepared for this type of development environment: as a solitary programmer in the design and development of desktop applications in which the user interface is a large component of the application (Greenberg, 1996). Not only must the "under the hood" algorithms and code that capture the business rules of the subject domain be designed and implemented, the solitary programmer must create the interactive sets of screens and/or implement the data feeds (i.e. inputs), and the screen and/or paper-based reports (outputs). The skill sets required to design and implement an interactive-based application go beyond "programming" capabilities. To be successful, as defined from a purely academic standpoint, programmers must approach applications development with a "systems analyst" mind-set. A systems analyst must account for the people, processes, data, network and technology in the business environment (Whitten et. al, 1994); a tall order for inexperienced developers.

The basic principles of human-computer interactions such as user-centered design and usability, paramount for a developer of desktop applications where the graphical user interface may well be the majority of the application's code, may not even be offered within the traditional computer science curriculum (Sears, 1997). As quoted from Myers (1992), studies found that an average of 48% of the code of applications is devoted to the user interface, and that about 50% of the implementation time is devoted to implementing the user interface portion. With its high degree of user interfaces, the quality of interactive software can be increased if it is designed to incorporate human factors engineering principles. Schneiderman (1992) suggests that when an interactive system is well designed, computer user interface virtually disappears from the end users' consciousness, allowing them to concentrate on accomplishing their goal. To the end user, the interface is the system (Constantine, 1995). This implies that the application must embody and emulate at least some of the end users' work tasks and processes, meaning that the developer must understand the business domain to some extent.

The traditional computer science curriculum is geared towards team-based, large-scale system development (Ghezzi, 1991), and graze over the foundational principles of software engineering (i.e. the bigger picture of the software development process, software project management, software testing, quality and defect management). The traditional college-level computer science curriculum strives to maintain balance between a breadth of study of the computer science discipline and the practical application of those principles. Used by many colleges and universities, the ACM/IEEE Computing Curricula 1991 organizes the core of computer science into 56 curriculum units, within eleven subject areas. Of the 283 total number of hours for the Liberal Arts degree, a relatively low percentage (6.7%) are for the "peopleware issues" of computer science -- 8 hours of Human-Computer Communications and 11 hours of Social and Ethical Issues. The other subject areas, with recommended hours in parentheses, are Algorithms & Data Structures (47), Computer Architecture (59), AI and Robotics (9), Database & Information Retrieval (9), Programming Languages (58), Numerical & Symbolic Languages (7), Operating Systems (31), and Software Methodologies & Engineering (44).

In many small-scale development environments in which there is no technical management oversight or availability, the solitary applications developer must self-manage the software development lifecycle. In this situation, methodology has less predominance, and the biggest influence on program quality is the skill of the individual writing the [application] program (McConnell, 1997). Appropriate time and effort must be expended to design and implement not only the application, but any deliverables of the application product. Brooks (1982) maintains that programs are written by individuals for their own use, whereas products are written for use by others. A product (versus a program) entails the whole "package": design and/or rationale documents, source code, screens, reports, end user training or training materials, on-line or paper-based help facilities. It is more than a handful of diskettes with zipped-up files that are the "code".

Needless to say, only certain people are cut out for solitary applications development. According to Kolb's (1981) Learning Style Inventory assessment, a person with a Converger learning style may be well suited as a computer programmer. Strengths of the Converger are problem solving, decision making, deductive reasoning and defining problems. However, weakness may be solving the wrong problem and hasty decision making. Software development is froth with problem solving and decision making, and the onus is on the solitary developer to single-handedly contend with these issues and problems.

Tools

Linthicum (1994) believes that the improper use of 4GL programming tools can cause more problems than its solves for many organizations. Their ease of use can lead developers to neglect formal analysis and design, important components of the software development life cycle. In close proximity to and coordinate with the end users, the application developer strives to produce a working prototype that evolves into a full-scale software application through an iterative "design-code-evaluation" methodology. This may increase the possibility of a more user-centered design (Grudin, 1991), but on the other hand, hinder the development due to false or premature expectations experienced by the end users (Linthicum, 1994). Jumping right into a "solution" for a vague "problem" can lead to a tunnel vision approach. The first solution (prototype) that the end users and system owners seem to like may rule out other, perhaps better solutions to the software engineering "problem". Swartout and Balzer (1982) stated that such decisions may result from "physical limitations and imperfect foresight".

Methods

Traditional software development methodologies, such as the Waterfall model or Boehm's Spiral model, are very document-driven, requiring considerable upfront requirements definitions and (current) systems analysis (Weinberg, 1991). In the small-scale applications environment, there is a greater chance of an "I'll know what I need when I see it" echo from the end user(s) than of a well-defined vision of a system requirement that can be communicated to the developer. Boehm (1988) suggests that the evolutionary development model is ideally matched to a fourth-generation language application, but not without its problems. Applications developed without sufficient investigation of the real business needs may fall victim to the "code and fix" trap, quickly reducing the likelihood of a quality software product that is easily maintainable and extendible. Nevertheless, the ability to jump right into the creation of a prototype is an alluring factor. Weinberg (1991) states that many developers "begin prototyping software systems without any real design or specifications from which to work".

In a 4GL programming environment, it's not unusual for the developer to start building screens, designed from a mental model of what the programmer knows about the domain or can gather right off of the bat. Prototyping has been a popular modeling technique used within the more traditional software development life cycles methodologies. Henson and Knezek (1991) propose that prototyping represents a change in development methodology that seeks to modify or replace, not enhance traditional methodologies. A researcher from University of Sunderland, UK (4/13/1997), proposes that the evolutionary development is a methodology closely related to, but clearly distinct from software prototyping. Verbatim from their web page:

"The fundamental difference between evolutionary development and software prototyping is that evolutionary development aims to replace the old system with a new system that satisfies the new requirements as quickly as possible. In contrast, software prototyping uses an iterative approach to satisfy the organizational requirements."

In other words, the use of prototyping assumes that requirements have been defined, and the prototyping iterations establish and model them. An evolutionary development approach assumes that system requirements change often, and each evolution of the system provides a fully functioning system that incorporates new requirements that had been specified since the previous system implementation. There continues to be conflicting definitions of the term 'prototyping' in the literature.

The use of 4GL tools, coupled with rapid application development techniques, allows software developers to produce attractive, complex systems within months (Louderback, 1992; Redmond-Pyle, 1996). Rapid application development (RAD) has relatively recently emerged as a development methodology for interactive software development. It is ideally suited for tight scheduled, 4GL-based projects where software requirements are vague and undocumented. Mortimer (1995) states that "rapid application development is an approach to Computer Systems Engineering which uses small teams, fourth generation languages, fast development, tight time-scales and resource constraints, iterative, evolutionary and participative prototyping and intensive user involvement amongst a variety of principles". He goes on to reference numerous works that emphasize that the developers were key, and that this methodology can guide but not substitute for experienced and skilled developers in reaching a satisfactory end product. Many traditional software developers see RAD as an excuse to avoid the rigorous disciplines required in developing sound and reliable systems (Rapley, 1995).

Conclusion and Future Research

Relatively little could be found in the literature with respect to the trials and tribulations of the solo applications developer. Larry Constantine, the father of structured analysis and analysis methodologies, and a second career path of clinic psychotherapy, conjured the phrase "coding cowboys" to describe an all-too-common style of individual programmers. In an environment where there is no technical oversight or guidance, or the enforcement of any standard methodologies, it is up to the individual developer to self-regulate and self-manage the software project. However, a sizable percentage of solitary developers are computer science graduates of the last decade, and are possibly unprepared to design and develop interactive software and application products. To design interactive applications, the developer must consider a myriad of factors, most importantly the peopleware issues such as human-computer interaction and the human-human interaction with end users! Works such as Humphrey's Personal Software Process that focus on how application developers can improve their professional endeavors are sorely needed.

The literature review also discovered weaknesses in the technical management and oversight of solitary applications developers. Literature in the area of project management of large teams and/or projects was readily available, but sparse in the areas of small teams and virtually nonexistent for solitary developers.

References

ACM/IEEE-CS Joint Curriculum Task Force. Computing Curricula 1991. ACM/IEEE-CS Joint Curriculum Task Force Report. ACM Press and IEEE Computer Society Press, 1991.

Boehm, W. B. (1988). A spiral model of software development and enhancement. IEEE Computer, 21(2), 61-76.

Brooks, Jr., F.P. (1982). The Mythical Man-Month. Reading, MA: Addison-Wesley.

Constantine, L. L. (1995). Constantine on Peopleware. Englewood Cliffs, NJ: Yourdon Press.

Ghezzi, C., Jazayeri, M., & Mandrioli, D. (1991). Fundamentals of Software Engineering. Englewood Cliffs, NJ: Prentice-Hall.

Greenberg, S. (1996). Teaching human computer interaction to programmers. SIGCHI Bulletin, 28(2), 5-6.

Grudin, J. (1991). Interactive systems: Bridging the gap between developers and users. IEEE Computer, 24(4), 59-69.

Harrison, J. V., Bailes, P. A., Berglas, A., & Peake, I. (1995). Re-engineering 4GL-based information system applications. Proceedings 1995 Asia Pacific Software Engineering Conference, Brisbane, Australia, 448-457.

Henson, K. L., & Knezek, G. A. (1991). The use of prototyping for educational software development. Journal of Research on Computing in Education, 24(2), 230-239.

Humphrey, W. (1997). Introduction to the Personal Software Process. Reading, MA: Addison Wesley.

Irwin, R. D. (1995). Presentation slides for use with Systems Analysis and Design Methods by Whitten, Bentley, and Barlow, 3rd Edition. In NSU DISS 725 class notes. Fall, 1997.

Kolb, D. A. (1981). Learning-Style Inventory. Boston, MA: McBer & Company.

Komiya, S. (1993). 4GL future directions. 3rd International Conference on Software Quality 1193, 389-396.

Linthicum, D. (1994). 4GLs: Productivity at what cost? DBMS, 7(5), 22-23.

Louderback, J. (1992, June 29). It's time to move past SDLC in app development. PCWeek, 9, 98-98.

Myers, B. A, & Rossen, M. J. (1992). Survey on user interface programming. In Human Factors in Computing Systems. Proceedings SIGCHI '92, 195-202.

McConnell, S. (1997). Less is more. Software Development, 5(10), 28-34.

Millington, D., & Stapleton, J. (1995). Developing a RAD standard. IEEE Software, 12, 54-55.

Mortimer, A. J. (1995). Project management in rapid application development. IEE Colloquim on Project Management for Software Engineers, Digest #1995/235.

Rapley, K. (1995). RAD or TRAD or both? The future of software development. IEE Colloquim on 'Will Techit and ISO9000 Survive RAD?', Digest #1995/237.

Redmond-Pyle, D. (1996). Software development methods and tools: Some trends and issues. Software Engineering Journal, 11, 99-103.

Schneiderman, B. (1992). Designing the User Interface. Reading, MA: Addison-Wesley.

Sears, A. (1997). HCI education: Where is it headed? SIGCHI Bulletin, 29(1), 7-9.

Swartout, W. B., & Balzer, R. (1982). On the inevitable intertwining of specification and implementation. Communications of the ACM, 25(7), 438-440.

University of Sunderland, UK, School of Computer and Information Systems. Evolutionary development. http://osiris.sund.ac.uk/calnwi/html/swproto/evdev.html. Accessed 4/13/97.

Weigers, K.E. (1993). Implementing software engineering in a small software group. Computer Languages, 10(6), 55-60,62-64.

Weinberg, R.S. (1991). Prototyping and the systems development life cycle. Journal of Information Systems Management, 8(2), 47-53.

Whitten, J. L., Bentley, L. D., & Barlow, V. M. (1994). Systems Analysis & Design Methods, Third Edition. Boston, MA: Richard D. Irwin, Inc.