Professional Documents
Culture Documents
177
next deadline or the next deliverable. RAD methodologies are clearly needed to produce
software quickly, and a compressed development life cycle requires powerful RAD tools.
But knowledge of how to incorporate RAD tools into an IS shops tool kit and the longterm implications of current usage patterns of RAD is woefully limited. Systems developers are assumed to be receptive to the new tools; indeed, the prevailing view amongst
IS management appears to be If we buy it, they will come. But mandating technology usage has long been recognized as an inappropriate management tactic for obtaining
buy-in and commitment from systems developers. Management must identify the types
of developers more likely to respond positively to RAD. Another perhaps unsubstantiated claim of RAD technology is its ability to build higher quality systems that are more
maintainable, reusable, and extensible [10]. Questions regarding precisely how RAD
tools are used remain unanswered. What are the pitfalls of RAD, and will the methodology truly address the software crisis? Will RAD tools provide business value in the
long-run, or do caveats exist that managers should be sensitive to?
In this article, we focus first on the steps needed to implement RAD tools, including
the types of developers more likely to be receptive to the technology and how it should
be positioned to maximize acceptance; and second, on usage patterns of RAD tools and
their relationship to perceived benefits. The research strategy utilized is one of triangulation: we use a broad-based cross-company survey to determine patterns of diffusion
and use, and to generate plausible explanations. We then verify explanations using richer data through interviews with practicing managers and analysts using the technology.
One RAD tool that supports all the features commonly associated with RAD was selected to control for possible variance arising from the tool itself. The results are somewhat
disturbing in regard to the changes in the development life cycle being wrought by the
tools.
178
RAD Implementation
RAD technologies incorporate a fundamentally different approach to systems development than the dominant software development approaches of the last three decades
[9]. RAD implies successive iteration, refinement, and an accelerated movement from
a prototype to a production system. As a tool it uses objects and message-passing
metaphors, and emphasizes reusability, visual programming, and graphical user interfaces. Given that the majority of IS professionals in the workforce today did not
receive formal training in such tools, issues exist related to acceptance of the new technology. Extensive research on the acceptance of innovations suggests that implementing and managing new technologies poses challenges of considerable magnitude.
We undertake an exploration of management interventions that can help facilitate
the assimilation of RAD technology using the research model shown in Figure 1. The
model identifies three perceptions that have been consistently related to positive usage
intentions, which predict actual usage of an innovation [1, 12]:
Relative advantage assesses the extent to which a developer believes the technology
represents an improvement over prior methods.
Ease-of-use measures the perceived cognitive effort necessary to effectively utilize
the new tool.
Compatibility measures perceived congruence of new technology with preferred
methods of accomplishing tasks.
The model identifies two additional factors, the study of which can also help formulate management interventions: individual difference, and method-of-implemention
variables. Prior studies focused primarily on the internal psychological processes that
lead to acceptance of new technologies; few have focused on how management might
proactively influence the process of acceptance (as opposed to compelling technology
use by edict). The individual difference variables of a developer include his/her: prior
mainframe and client/server experience and personal innovativeness with respect to
new information technologies.
Our selection of these variables was based on extensive research in learning theories
and the diffusion of innovations. In the human-associative view of learning, the law of
proactive inhibition suggests that prior experiences can affect the ability to learn new
behaviors, depending on the extent of similarity between prior experiences and the new
behavior to be learned. Similar experiences promote positive attitudes toward the new
object while dissimilar experiences influence learning and attitudes negatively. Research
examining skills transfer of systems analysts experienced in process-oriented modeling
identified a performance deterioration when analysts moved to an OO modeling environment [2]; thus, empirical support exists for a persistent assumption in the IS communitythat developers with significant experience in more traditional systems construction methods have more difficulty accepting new development paradigms. Perhaps
their experience with the extensive discipline and structure associated with mainframebased projects makes them skeptical of the seemingly ad hoc nature of RAD. The
introduction of a RAD life cycle is alarming and threatening to professionals comfortable with an older and slower methodology, notes Martin [9]. In addition to the prior
experience of a developer, his/her personal innovativeness in the domain of information
COMMUNICATIONS OF THE ACM
179
technology, defined as the propensity of an individual to try out any new information
technology, has also been shown to significantly influence behavior toward a technology innovation [8].
The method-of-implementation variable includes a measure of the speed of RAD
technology adoption, as well as a developers assessment of the scope of the change
the radicalness of its departure from existing software development and delivery paradigms. Gallivan et al. point out that strategies for the successful assimilation of any
new technology necessitate attentiveness to the speed of its introduction into an organization, as well as to the extent to which the change represents a radical as opposed to
an incremental modification of current practice. The items used to measure each construct are shown in Table 1.
180
of RAD tools relates to benefits, or what features of RAD tools are even being utilized. The model presented in Figure 2 is used to explore the relationship between
RAD tool usage and expected outcomes. Outcomes are categorized into two classes
based on a review of the literature. The global benefits class includes overall application development productivity, resource consumption, and overall management of
software development projects. Specific outcomes represent more micro-level values
like greater application development flexibility, reduced coding, and code reuse
(Table 2). RAD tool features are organized into three categories, based on their roles
in the overall software development process. The project management class includes
features such as configuration and version management and team repository management; the development class includes, among others, interactive debugging, screen
layouts and navigation, and GUI code generation; and the modeling class consists of
data and business process modeling.
181
The organizations using RAD tend to be reasonably large, with an average of approximately 2,800 employees, approximately 10% of whom work in IS. The bulk of the
industries represented are service-oriented, and thus their ability to deploy new IT
applications in a timely manner is often a major source of competitive advantage.
Iivari points out that some of the early studies of IT process innovations such as
CASE tools did not sufficiently ensure reliability and validity of the measures [7]. The
constructs in the two research models are thus rigorously operationalized using previously validated scales. As Tables 1 and 2 show, multi-item scales were utilized for all
research constructs, except for two developer characteristics: prior mainframe experience and prior client/server experience. These two were measured by survey questions
that asked respondents the length of time they worked with both sets of technologies.
RAD technology usage was assessed by asking respondents to rate the extent to which
they utilized each feature of the tool in software development. Usage was scored on a 7point scale, with the end points anchored at Not at all used and Used whenever
appropriate. Responses on all features belonging to a particular class were averaged to
obtain a feature usage score for the class. A similar procedure was utilized for operationalizing the global and specific benefits of RAD. Descriptive statistics for all research
variables, as well as scale reliabilities are shown in Table 4. The reliability values for all
scales are indicative of high internal consistency. Multivariate procedures were utilized
to test both research models.
COMMUNICATIONS OF THE ACM
182
Findings
The data reveals that on average, developers have neither overwhelmingly negative or
positive perceptions of the RAD tool. Recall that the first research model identified
the systems developers most likely to be most receptive to RAD and to transition
from old to new skills, and addressed how managers desiring to implement RAD
should position it to developers. A multivariate analysis of variance (MANOVA) procedure was utilized with developer characteristics and implementation characteristics
as independent variables, and the three salient perceptions about RAD as dependent
variables. The overall F-test for the MANOVA was significant; univariate tests
revealed that the personal innovativeness of an individual developer in the domain of
information technology was a significant determinant of all three perceptions, while
prior client/server experience had a negative effect on perceptions of compatibility
(Table 5). Among the implementation characteristics, the scope of the change had a
positive effect on all three perceptions.
The second research model was also tested using a MANOVA procedure, because of
the expectation that global benefits and specific benefits are likely to be correlated.
Although the overall relationship between the two benefit categories and the three feature sets was significant at p < 0.1, a significant coefficient was obtained only for the
usage of development related features as a predictor of global benefits ( = 0.379, t-value
= 2.21, p < 0.05).
Discussion
Although not reported here, several studies examining technology acceptance indicate
that perceptions about the RAD tool were significant predictors of usage intentions.
Clearly, management needs to focus on developing positive perceptions about the
new technology to ensure its successful adoption into the IS organizations tool kit.
Two developer characteristics among the determinants of perceptionsprior
client/server experience and personal innovativenessemerged as significant predictors. An encouraging finding was the absence of a relationship between prior mainframe experience and perceptions about RADthis relationship might have been
COMMUNICATIONS OF THE ACM
183
184
eling emerge as highly correlated with perceived benefits? One explanation is that these
results suggest a subversion of development methodology, and perhaps systems developers are ignoring or side-stepping crucial phases in the development life cycle. Further
support for this explanation can be found in the fact that the difference between usage
of development features compared with modeling features was statistically significant.1
Systems developers appear to be utilizing the features of the tool that allow them to
deliver systems in a speedy manner, but are not fully utilizing the features that contribute to longer-term quality and maintainability of systems. This confirms the supposition articulated in a recent debate on RAD that most RAD projects skip design
and rigorous methodology altogether.[10]
To gain further insight into the underlying issues our findings point to, we gathered
follow-up data, with the intent of gaining a rich, qualitative understanding of the RAD
phenomenon as observed by systems developers. Particular emphasis was placed on any
changes to the systems development process wrought by the technology. Four organizations, Alpha, Beta, Gamma, and Delta were targeted for interviews: two of which utilized the same tool that formed the basis for the survey. In order to ensure the results
obtained were not idiosyncratic to the particular tool being studied, two organizations
using a different RAD tool for software development were also included. Alpha is a large
information provider that operates in the financial and insurance sectors. Its primary
line of business is providing information about consumers to retail companies. For
instance, Alpha provides insurance companies with information about all previous
claims made by a new applicant for an insurance policy. Beta is a mid-sized utility company that provides electricity and gas services to approximately one million customers.
Gamma is a large investment bank that provides personal and institutional client brokerage services; it is in the top 10 of its kind, ranked internationally. Delta is a large
manufacturing organization that develops highly engineered products for a global marketplace. In each case, interviewees were IS managers with direct responsibility for projects utilizing RAD tools. The interviews were structured around their experiences with
RAD and their overall impressions of what changes the technology was instrumental in
bringing about.
185
unreasonably high. For example, a project that required about 35 screens, an interface to a Sybase database, and a mainframe Cobol database was estimated to be of
medium size by the project teamthis estimate was halved by management.
Regarding assimilation and implementation of RAD, respondents noted that people
with linear C experience had the most difficulty in making the transition. Even developers with client/server experience did not adapt to the tool very quickly, simply
because of the paradigm shift from procedural to OO development. The Beta manager explained that he did not feel he could mandate use of the tool, but he was attempting to influence his staffs attitude by emphasizing benefits such as its multitier capability, potential impacts on reusability, and database independence.
Perhaps the most disturbing aspect of the tools revealed by the interviews, consistent
with what the survey data suggested, was the profound impact that RAD tool use was
having on development methodology. The Gamma manager was particularly concerned; in his view, the most alarming change he witnessed since RADs adoption into
his IS organization was the declining emphasis on requirements planning and modeling. We are already under the gun to deliver applications quickly. Now the tools let you
show users something very quick and very dirtytheres immediately an expectation
that the system is ready. Theres very little incentive for the developer now to say lets go
back to the drawing board and see if we have the domain model nailed down accurately. The attitude is that the tools make changes and multiple iterations so easy that errors
and mis-specifications can always be caught down the road and fixed. To me this poses
a very great dangerhow are we going to realize the benefits of reusability if we keep
shrinking the analysis phase? This sentiment was echoed by the manager at Beta, who
noted that the rapid prototyping capability of these tools had resulted in the use of a
seat of the pants methodology. The key concerns about RAD that surfaced through
the survey and field interviews are:
Development-related features of RAD tools used more extensively than modeling
features;
Declining emphasis on requirements planning and modeling;
Potential subversion of development methodology; major emphasis on system
construction, not enough on domain analysis;
Developer tendency to not seek out errors and misspecifications early in the development cycle;
Benefits of reusability cannot be obtained with a shrinking analysis phase;
Unrealistic management expectations about how quickly systems can be constructed using RAD approaches; and
Developers with linear C experience have difficulty making the transition to
object-based RAD tools.
186
must be paid to the developers who are first targeted for RAD and the manner in
which the technology is brought into the IS organization. Developers who are personally more innovative with respect to information technology and have greater
exposure to OO technology are inclined to respond to RAD with more alacrity. These
individuals can serve as key change agents in diffusing the technology more widely.
Because such developers are likely to be more recent entrants into the software development world, managers might wish to staff RAD projects with a mix of old and new
skills, where the business knowledge and methodology commitment of experienced
staff combines and diffuses synergistically with the receptivity to new technology of
the newer developers. Managers also need to emphasize the magnitude of the change
represented by RAD over previous approaches to software construction, perhaps
through the use of information dissemination and training sessions. Training should
not focus only on imparting technical knowledge, but on underscoring the radical
improvement RAD represents.
IS organizations adopt RAD methods and tools in an attempt to realize both productivity and quality benefits. Our results show that managers need to try to avoid the
pitfall of allowing RAD capabilities to subvert good development practices. Martin
notes that higher quality, lower cost, and rapid development, thus, go hand in hand
if an appropriate development methodology is used [9]. In a study of the factors affecting reuse, Frakes and Fox found that a common software process and reuse education
were important determinants of reuse, while the specific programming language or
CASE tool were not [5]. The dominant driver of an individual developers behavior,
only exacerbated by the increasing pressure from users, tends to be the next short-term
deliverable. Convincing such developers of the importance of up-front domain analysis
and modeling represents a critical area for managerial emphasis if RAD is truly going to
help alleviate the software crisis. At the very least, the decision by managers to yield to
short-term business pressures by sacrificing analysis and using RAD for speed alone (to
deliver systems quickly that are intended to be fixed in later iterations)should be an
informed decision, made after consideration of the implications on cost and quality in
the longer term. Clearly, this is an issue that merits widespread debate.
References
1. Ajzen, I. and Fishbein, M. Understanding Attitudes and Predicting Social Behavior. Prentice-Hall,
Englewood Cliffs, NJ, 1980.
2. Agarwal, R., Sinha, A.P., and Tanniru, M. The role of prior experience and task characteristics
in object-oriented modeling: An empirical study. International Journal of Human-Computer Studies
46 (1996), 639637.
3. Banker, R. and Kauffman, R.J. Reuse and productivity in computer-aided software engineering: An empirical study. MIS Quarterly 15, 3 (1991), 375401.
4. Creegan, R.W. RAD may be the answer. Computing Canada 20, 13 (June, 1994), 43.
5. Frakes, W.B. and Fox, C.J. Sixteen questions about software reuse. Commun. ACM 38, 6 (June
1995), 7587.
6. Gallivan, M. J., Hofman, J.D. and Orlikowski, W. Implementing radical change: Gradual versus rapid pace. In Proceedings of the 15th International Conference on Information Systems (Dec.
1417, Vancouver, BC) ACM/SIGBIT, New York, 1994, 325339.
7. Iivari, J. Why are CASE tools not used? Commun. ACM 39, 10 (Oct. 1996), 94103.
187
188