This article was downloaded by: [193.146.32.

73] On: 24 April 2014, At: 15:36

Publisher: Institute for Operations Research and the Management Sciences (INFORMS)
INFORMS is located in Maryland, USA

Management Science
Publication details, including instructions for authors and subscription information:
http://pubsonline.informs.org

Software Development Practices, Software Complexity,

and Software Maintenance Performance: A Field Study
Rajiv D. Banker, Gordon B. Davis, Sandra A. Slaughter,

To cite this article:

Rajiv D. Banker, Gordon B. Davis, Sandra A. Slaughter, (1998) Software Development Practices, Software Complexity,
and Software Maintenance Performance: A Field Study. Management Science 44(4):433-450. http://dx.doi.org/10.1287/
mnsc.44.4.433

Full terms and conditions of use: http://pubsonline.informs.org/page/terms-and-conditions

This article may be used only for the purposes of research, teaching, and/or private study. Commercial use
or systematic downloading (by robots or other automatic processes) is prohibited without explicit Publisher
approval. For more information, contact [email protected].

The Publisher does not warrant or guarantee the article’s accuracy, completeness, merchantability, fitness
for a particular purpose, or non-infringement. Descriptions of, or references to, products or publications, or
inclusion of an advertisement in this article, neither constitutes nor implies a guarantee, endorsement, or
support of claims made of that product, publication, or service.

© 1998 INFORMS

Please scroll down for article—it is on subsequent pages

INFORMS is the largest professional society in the world for professionals in the fields of operations research, management
science, and analytics.
For more information on INFORMS, its publications, membership, or meetings visit http://www.informs.org
 Software Development Practices, Software
Complexity, and Software Maintenance
Performance: A Field Study

Rajiv D. Banker j Gordon B. Davis j Sandra A. Slaughter

Downloaded from informs.org by [193.146.32.73] on 24 April 2014, at 15:36 . For personal use only, all rights reserved.

School of Management, University of Texas at Dallas, Richardson, Texas 75083

Carlson School of Management, University of Minnesota, Minneapolis, Minnesota 55455
Graduate School of Industrial Administration, Carnegie Mellon University, Pittsburgh, Pennsylvania 15213

S oftware maintenance claims a large proportion of organizational resources. It is thought that

many maintenance problems derive from inadequate software design and development
practices. Poor design choices can result in complex software that is costly to support and dif-
ficult to change. However, it is difficult to assess the actual maintenance performance effects of
software development practices because their impact is realized over the software life cycle. To
estimate the impact of development activities in a more practical time frame, this research de-
velops a two-stage model in which software complexity is a key intermediate variable that links
design and development decisions to their downstream effects on software maintenance. The
research analyzes data collected from a national mass merchandising retailer on 29 software
enhancement projects and 23 software applications in a large IBM COBOL environment. Results
indicate that the use of a code generator in development is associated with increased software
complexity and software enhancement project effort. The use of packaged software is associated
with decreased software complexity and software enhancement effort. These results suggest an
important link between software development practices and maintenance performance.
(Software Maintenance; Software Complexity; Software Productivity; Software Quality; Software Eco-
nomics; Software Metrics; Management of Computing and Information Systems)

1. Introduction than three-fourths of the investment in software occurs

Although Edward Yourdon claims that ‘‘maintaining a after the system has been implemented (Arthur 1988).
computer program is one of life’s dreariest jobs . . . for Thus, there is considerable motivation to improve soft-
most American programmers, it is a fate worse than ware maintenance performance.
death’’ (in Zvegintzov 1988, p. 12), software mainte- Software maintenance is an activity that is difficult to
nance is an important problem for organizations. Soft- perform and manage effectively (Swanson and Beath
ware maintenance is the modification of a software sys- 1989). It is thought that many problems in software
tem after delivery to correct faults, improve perfor- maintenance result from inadequate practices in soft-
mance, or adapt to a changed environment (ANSI/IEEE ware development (Schneidewind 1987). Software sys-
1983). Over the last several decades, software mainte- tems are the legacy of the tools, techniques, and people
nance has been claiming a large proportion of organi- involved in their creation. Because systems have a life-
zational resources, with expenditures often as high as time often measured in decades (Zvegintzov 1984),
50–80 percent of the information systems (IS) budget long-term costs of supporting poor quality software can
(Nosek and Palvia 1990). On a life-cycle basis, more be substantial. Thus, actions to achieve improvements

0025-1909/98/4404/0433$05.00
Copyright q 1998, Institute for Operations Research
and the Management Sciences MANAGEMENT SCIENCE/Vol. 44, No. 4, April 1998 433

3b28 0008 Mp 433 Monday Apr 06 08:40 AM Man Sci (April) 0008
 BANKER, DAVIS, AND SLAUGHTER
Software Development Practices, Software Complexity, and Maintenance Performance

must begin when the software is initially designed or key performance and design issues for the support of
when existing software is re-engineered. However, be- business software.
cause the major benefits and penalties of development
tools and techniques for software maintenance are re-
alized over the software life cycle, it is difficult to assess 2. Theoretical Framework
their actual maintenance performance effects. There- The theoretical framework for this study is developed
fore, a critical barrier to improvement in software main- by integrating several different perspectives. A produc-
Downloaded from informs.org by [193.146.32.73] on 24 April 2014, at 15:36 . For personal use only, all rights reserved.

tenance is the lack of knowledge concerning the impli- tion economics perspective enables specification of an
cations of development practices for maintenance per- integrative model for software development and main-
formance. This provides the motivation for the central tenance. A psychological perspective forms the basis for
issue examined by this study: the effect of software de- conceptualizing software maintenance performance
velopment practices on software maintenance perfor- and motivates the choice of software complexity as a
mance. key variable influencing performance.
This study posits that the impact of development
practices on software maintenance can be assessed 2.1. Economic View of Software Development and
within a practical time frame by considering their ef- Maintenance
fects on software complexity (Banker et al. 1989). Gen- Building upon the conceptual foundations of Kriebel
erally, software complexity refers to the characteristics and Raviv (1980), Stabell (1982), and Banker et al.
of the data structures and procedures within the soft- (1991), this study views software development and
ware that make it difficult to understand and change maintenance as economic production processes. In
(Curtis et al. 1979). Software complexity is emerging these processes, input factors including labor (the
as a critical software design quality factor (Card 1992, programming team) and capital (tools and tech-
Card and Glass 1990). Furthermore, there is growing niques) are transformed into outputs such as new or
empirical evidence that software complexity is a major modified software (Figure 1). A production econom-
factor influencing maintenance effort (Kemerer 1995, ics perspective reveals two issues germane to this
Banker et al. 1993, Gibson and Senn 1989). However, study. The first issue is the unidirectional flow of in-
there is little knowledge of the link between develop- formation between the development and mainte-
ment practices and software complexity, and the sub- nance processes. Although many software mainte-
sequent implications for maintenance. This limits the nance problems result from poor design choices, the
extent to which managers can take proactive steps to traditional life-cycle model of software development
improve software quality and reduce long-term main- discourages communication of feedback from main-
tenance costs. tenance into development (Schneidewind 1987). This
The study develops an integrative model, using soft- lack of knowledge transfer has the result of locking
ware complexity as an intermediate variable that links organizations into suboptimal processes (Senge 1992)
development decisions to their downstream effects on in which they support low quality software that can-
software maintenance performance. The model is esti- not easily be modified.
mated using data collected from a national mass mer- Another issue highlighted by a production eco-
chandising retailer on 29 software enhancement projects nomics perspective is the difference in inputs to the
and 23 software applications in a large IBM COBOL en- software development and maintenance processes.
vironment. Although businesses spend considerable While both development and maintenance employ
amounts on software, empirical studies of software in people, tools, and techniques to produce software, a
commercial environments are rare, due to difficulties in unique input to the maintenance process is the soft-
obtaining primary data from organizations (Hale and ware that is created by the development process. This
Haworth 1988). By examining both software develop- implies that the quality of the existing software plays
ment and software maintenance in a commercial envi- an important role in software maintenance perfor-
ronment, this research provides unique insights into mance.

434 MANAGEMENT SCIENCE/Vol. 44, No. 4, April 1998

3b28 0008 Mp 434 Monday Apr 06 08:40 AM Man Sci (April) 0008
 BANKER, DAVIS, AND SLAUGHTER
Software Development Practices, Software Complexity, and Maintenance Performance

Figure 1 Software Development and Maintenance Production Processes

Downloaded from informs.org by [193.146.32.73] on 24 April 2014, at 15:36 . For personal use only, all rights reserved.

2.2. Psychological View of Software Maintenance cated than any other human construct (1986, p. 11).
and Software Complexity Studies of software complexity suggest that software
While an economic perspective conceptualizes software has multiple dimensions (Zuse 1990, Munson and
maintenance as a production activity and enables insights Khoshgoftaar 1989, Weyuker 1988, Li and Cheung
into managerial concerns, a psychological perspective pro- 1987). Furthermore, software maintainers are often re-
vides insights at the level of the individual maintenance quired to modify software that is ill-documented, lacks
task. Software maintenance can be conceptualized as a comprehensible structure, and hides data representa-
cognitive, human information-processing task in which tions (Guimaraes 1983). Thus, software maintenance
input informational cues are interpreted and manipulated becomes a largely cognitive task in which programmers
to create task outcomes (Ramanujan and Cooper 1994, Da- perceive and manipulate relationships between infor-
vis et al. 1993). According to this view, performance on mational cues presented by the existing software (Pen-
cognitive tasks depends on effective processing of infor- nington 1987, Shneiderman 1980).
mational cues in the task environment (Simon 1981). Empirical studies suggest that a significant portion of
A key factor believed to influence cognitive task per- the software maintainer’s time is required to understand
formance is complexity (Locke and Latham 1990, the functionality of the software to be changed (e.g., Litt-
Campbell 1988, Wood et al. 1987, Simon 1981). Com- man et al. 1987). A study of professional maintenance
plexity is a phenomenon with multiple dimensions programmers by Fjeldstad and Hamlen (1983), for ex-
(Boulding 1970) in the form of component, coordina- ample, found that the programmers studied the original
tive, and dynamic complexity (Wood 1986). Component software code 3.5 times as long as they studied the sup-
complexity refers to the number of distinct information porting documentation, and equally as long as they spent
cues that must be processed in the performance of a implementing the enhancement. This suggests that soft-
task, while coordinative complexity describes the form, ware comprehension plays a major role in software main-
strength, and interdependencies of the relationships be- tenance performance. Another implication is that software
tween the information cues. Dynamic complexity arises complexity degrades maintenance performance because it
from changes in the relationships between information interferes with understanding the functionality of the soft-
cues over time, particularly during task performance. ware. Thus, this study argues that software complexity is
Because complexity obscures the perception and under- a key maintenance performance factor because it influ-
standing of information cues, it is believed to signifi- ences the critical activity of program comprehension.
cantly degrade task performance.
This psychological view of complexity is particularly 2.3. Research Models and Hypotheses
appropriate for studying software maintenance. Ac- The theoretical framework for this study is presented in
cording to Brooks, software entities are more compli- Figure 2. The framework integrates two models in which

MANAGEMENT SCIENCE/Vol. 44, No. 4, April 1998 435

3b28 0008 Mp 435 Monday Apr 06 08:40 AM Man Sci (April) 0008
 BANKER, DAVIS, AND SLAUGHTER
Software Development Practices, Software Complexity, and Maintenance Performance

Figure 2 Theoretical Framework for Software Maintenance Performance

Downloaded from informs.org by [193.146.32.73] on 24 April 2014, at 15:36 . For personal use only, all rights reserved.

software complexity links software development practices operationalized in terms of its component, coordinative,
to maintenance performance. The model for maintenance and dynamic dimensions. Software component complexity
performance examines the effects of software complexity is higher in software with ‘‘denser’’ code, where data
on maintenance project effort, controlling for factors such density refers to the number of data elements embedded
as project team experience, size of functionality modified, in each procedural line of code. A high level of data
and other application and project factors. In this study, we density increases the number of information cues the
focus on maintenance projects that adapt or enhance soft- maintenance team must perceive and process in order
ware functionality for existing systems because software to comprehend the software and to validate the modi-
enhancements represent the largest category of IS main- fications, and should increase effort required for the
tenance expenditures (Nosek and Palvia 1990). The model project. Prior empirical research generally supports the
for application software complexity connects maintenance notion that programs with higher density are associated
outcomes to software practices by assessing the impact of with increased maintenance effort (Shen et al. 1985,
development tools and techniques on the complexity of Gremillion 1984). Thus,
the software application. A detailed explanation of each
model follows. HYPOTHESIS 1 (COMPONENT COMPLEXITY ). Software
enhancement project effort is positively related to data density
2.3.1. Software Maintenance Performance Model. for the software modified.
The conceptual model for software maintenance perfor-
mance is illustrated in Figure 3. Software maintenance per- Software coordinative complexity is high where there
formance is operationalized as software enhancement is excessive decision density within the software under
project effort. Software enhancement includes modifica- modification. Frequent decision branching between
tions to extend, change, and delete the functionality of modules obscures the relationship between program
existing software. Project effort refers to the time required inputs and outputs and increases cognitive load on
by the maintenance project team to accomplish the soft- the maintenance team because they must search
ware modifications for a particular end user request. In among dispersed pieces of code to determine logical
this model, software enhancement effort is specified as a flow. This is supported by several empirical studies
function of software component complexity, software co- that have found that maintenance effort increases as
ordinative complexity, software dynamic complexity, branching complexity increases (Boehm-Davis et al.
project team experience, software functionality modified, 1992, Gill and Kemerer 1991). Thus, complex decision
application size, and application quality. branching should have a detrimental effect on project
Dimensions of software complexity map well onto effort because more time is required to follow the flow
the dimensions of complexity identified by Wood of logic within the code. This suggests the following
(1986). As shown in Figure 3, software complexity is hypothesis:

436 MANAGEMENT SCIENCE/Vol. 44, No. 4, April 1998

3b28 0008 Mp 436 Monday Apr 06 08:40 AM Man Sci (April) 0008
 BANKER, DAVIS, AND SLAUGHTER
Software Development Practices, Software Complexity, and Maintenance Performance

Figure 3 Model 1: Software Maintenance Performance

Downloaded from informs.org by [193.146.32.73] on 24 April 2014, at 15:36 . For personal use only, all rights reserved.

HYPOTHESIS 2 (COORDINATIVE COMPLEXITY ). Soft- nificant influence on maintenance performance. Wood

ware enhancement project effort is positively related to deci- (1986) argues that experience plays an important role in
sion density for the software modified. task performance because it influences an individual’s
ability to process complex informational cues. There-
Software dynamic complexity is higher when there is fore, the study controls for project team experience and
increased instability of the input-output relationship for expects it to be inversely related to project effort. Also
a task. An aspect of dynamic software complexity that controlled is the amount of software functionality modi-
is hypothesized to have a detrimental effect on main- fied. Functionality is not usually under the control of the
tenance performance is decision volatility. Decision vol- maintenance team, but rather is an inherent aspect of
atility refers to the use of statements that enable modi- the user modification request. Larger changes to soft-
fications to control flow at execution time such as ware functionality require additional activities in un-
dynamically invoked subroutines. Decision volatil- derstanding, validation, and implementation. Thus, the
ity should increase maintenance effort because pro- amount of modified functionality should be positively
grammers must envision the multiple, potential control related to project effort.
flow paths that could be followed and the procedures Other project factors that are controlled include ap-
that could be invoked when the program executes. Ef- plication size and quality. Enhancements to larger appli-
fort required for testing and validation of modifications cations require more effort due to difficulties in locating
to dynamically complex software may be higher be- the code to be changed and in validating changes
cause programmers cannot easily anticipate the condi- (Swanson and Beath 1989). The quality of the applica-
tions that arise when the software executes, and may
tion software also influences maintenance performance.
not be able to identify and validate all potential logic
Applications of poor quality that have had large
paths. This leads to the following hypothesis:
amounts of corrective modification are more difficult to
HYPOTHESIS 3 (DYNAMIC COMPLEXITY ). Software en- change. A high amount of repair suggests that an ap-
hancement project effort is positively related to decision vol- plication was poorly written or inadequately tested. In
atility for the software modified. addition, successive changes tend to complicate the
logic flows within the software (Guimaraes 1983).
There are several important aspects that are con-
trolled in the software maintenance performance model. 2.3.2. Software Complexity Model. To link main-
One aspect pertains to the characteristics of the project tenance performance outcomes to software develop-
team. Prior empirical research (Vessey 1989, Oman et ment practices, the study examines the intermediate ef-
al. 1989) suggests that project team experience has a sig- fect of software complexity. Software component

MANAGEMENT SCIENCE/Vol. 44, No. 4, April 1998 437

3b28 0008 Mp 437 Monday Apr 06 08:40 AM Man Sci (April) 0008
 BANKER, DAVIS, AND SLAUGHTER
Software Development Practices, Software Complexity, and Maintenance Performance

complexity, software coordinative complexity, and soft- grams generated by code generators include standard
ware dynamic complexity are all specified as functions routines and custom software routines that execute con-
of software development practices (Figure 4). Two soft- ditionally depending on inputs entered by the end user
ware practices are analyzed in this model: use of code of the system. This conditional invocation of custom
generators and packaged software. Both code generators code is very similar to the use of the ‘‘ALTER’’ or ‘‘GO
and packaged software are commonly used in software TO DEPENDING ON’’ statements that enable dynamic
practice. Use of code generators is believed to contribute modifications of program control flow at execution
Downloaded from informs.org by [193.146.32.73] on 24 April 2014, at 15:36 . For personal use only, all rights reserved.

to improved software quality and reduced maintenance time. These routines are necessary to particularize the
costs (Olle et al. 1983). Code generators require entry of software to user requirements not met by the code gen-
a specified set of parameters and create similar kinds of erator’s standard routines. The conditional execution of
software routines based upon these parameters (Davis custom code based upon online screen input makes it
and Olson 1985). Because code generators automate cre- difficult for maintenance programmers to discern the
ation of voluminous amounts of standard procedural logical flow of information within the program because
code to process a limited number of input parameters the programmers must envision dynamic characteristics
(Everest and Alanis 1992, Stamps 1987), use of these of program inputs from an online environment, infer
tools should reduce data density. This suggests that, which routines will be called and executed, and deduce
the subsequent effects on outputs. Thus, extensive use
HYPOTHESIS 4 (CODE GENERATORS ). The use of code of custom routines contributes to increased decision
generators is inversely related to data density for the appli- volatility in the software created by the code generator
cation software. because the routines complicate the standard control
Use of these tools should also introduce a consistent flow in the programs. This implies,
structure in the software and reduce decision density. HYPOTHESIS 6 (CODE GENERATORS ). The use of code
Thus, generators is positively related to decision volatility for the
application software.
HYPOTHESIS 5 (CODE GENERATORS ). The use of code
generators is inversely related to decision density for the ap- Packaged software is created by vendors to satisfy the
plication software. requirements of a large number of customers. Such soft-
ware includes a larger volume of data and procedures
However, although code generators enable produc- that apply more generally to a number of organizations
tivity gains in software development because of the au- (Davis 1988, Martin and McClure 1983). Thus, this kind
tomatic generation of code, such gains are offset in soft- of software should have higher data and decision den-
ware maintenance by increased decision volatility. Pro- sity than software developed in-house because it is not

Figure 4 Model 2: Software Complexity

438 MANAGEMENT SCIENCE/Vol. 44, No. 4, April 1998

3b28 0008 Mp 438 Monday Apr 06 08:40 AM Man Sci (April) 0008
 BANKER, DAVIS, AND SLAUGHTER
Software Development Practices, Software Complexity, and Maintenance Performance

restricted to the particular requirements of an organi- answering user questions, and accomplishing user-
zation (Lynch 1984). Thus, requested enhancements to existing functionality.
The Retailer has a large investment in transaction-
HYPOTHESIS 7 (PACKAGED SOFTWARE ). The use of
processing software written in COBOL and running on
packaged software is positively related to data density for the
large IBM mainframe computers. The study of software
application software.
maintenance in this kind of environment is important
HYPOTHESIS 8 (PACKAGED SOFTWARE ). The use of because a large portion of business expenditures for
Downloaded from informs.org by [193.146.32.73] on 24 April 2014, at 15:36 . For personal use only, all rights reserved.

packaged software is positively related to decision density for computing is still devoted to maintenance of COBOL
the application software. software (Croxton 1994). Approximately 65 percent of
the Retailer’s application portfolio at the time of the
However, decision volatility in the form of invoked
study was written in COBOL. Most of the application
subroutines would be lower in packaged software. To
software was written in the 1970s and 1980s, with the
facilitate incorporation of new releases from the vendor,
oldest system written in 1974.
organizations operate purchased software in isolation
The Retailer employs two primary development prac-
from their other applications, with the exception of nec-
tices: use of software packages and use of a code gen-
essary interfaces. As part of the vendor agreement, the
erator. Four of the 23 applications are software pack-
organization may be prohibited from major custom-
ages. The Retailer uses software packages for applica-
ization of the purchased software code. Thus, packaged
tions that are considered to be ‘‘generic,’’ with relatively
software tends to be less integrated into the application
little unique, company-specific requirements. The pack-
portfolio, with less invocation of organizational subrou-
ages are financial and accounting applications including
tines. This implies that,
payroll, general ledger, fixed asset accounting, and fi-
HYPOTHESIS 9 (PACKAGED SOFTWARE ). The use of nancial accounting. Agreements with the vendors for
packaged software is inversely related to decision volatility these packages do not prevent the Retailer from modi-
for the application software. fying the package software code. The Retailer has made
minor modifications to the packages such as customiz-
3. Research Design and ing the printing routines to accommodate the company
name and other unique identifiers.
Methodology The Retailer uses a code generator for in-house de-
3.1. Research Setting velopment. The code generator is a mainframe software
The research site is the IS department of a national mass productivity tool widely available in the 1980s and
merchandising retailer (hereafter referred to as ‘‘Re- 1990s that is intended to aid in the development of
tailer’’), located at company headquarters and support- COBOL applications. It provides support for the design
ing all centralized computer processing activities. In of online screens, for automatic generation of standard
1983, the IS department was divided into separate de- source code for input and output processing, and for
velopment and maintenance teams, with Development interactive testing of the generated source code. The tool
working exclusively on new systems, and Maintenance allows incorporation of custom source code within the
devoted to support and enhancement of existing sys- generated code to accomplish more complex or unique
tems. At the time of the study, Maintenance was re- processing that is not supported automatically, to mod-
sponsible for the support of 23 major applications. An ify the default program flow, and to override default
application at the Retailer includes a number of pro- field attributes. There was considerable interest in
grams or modules (on average, about 200 programs) studying the impacts of the code generator and pack-
that together accomplish a major function such as ac- ages on Maintenance, because the Retailer relied heavily
counts receivable, payroll, or order management. Main- on these development practices:
tenance supports these applications by correcting er- All of our development work now is done using code genera-
rors, doing preventative maintenance and conversions tors or its packages. The trend is to scope down by buying it
to accommodate changes in the technical environment, off the shelf or increase the number of people and tools to get

MANAGEMENT SCIENCE/Vol. 44, No. 4, April 1998 439

3b28 0008 Mp 439 Monday Apr 06 08:40 AM Man Sci (April) 0008
 BANKER, DAVIS, AND SLAUGHTER
Software Development Practices, Software Complexity, and Maintenance Performance

it done quicker. (Interview Transcript, Development Manager, since personnel time is the most expensive and scarce
February 8, 1993)
resource in software maintenance (Grammas and Klein
1985). A potential threat to validity of the effort measure
3.2. Data Collection Methods
is inaccurate project records. The Retailer’s internal cli-
Both quantitative and qualitative data were collected
ents were charged by the hours spent on their projects.
during the study. Multiple methods of data collection
This motivates personnel to maintain accurate project
and multiple data sources were employed, including in-
time records. In addition, the project data did not reveal
terviews, observation of meetings, project documenta-
Downloaded from informs.org by [193.146.32.73] on 24 April 2014, at 15:36 . For personal use only, all rights reserved.

any systematic bias or unusual observations that could

tion, software archives, data archives, computer listings,
not be explained by logical causes when various subsets
internal company reports and memos, media informa-
of the data were examined.
tion, and questionnaires. The triangulation made pos-
Software development practices include the use of a code
sible by multiple data collection methods and sources
generator and packaged software. The use of a code
provides stronger substantiation of constructs and hy-
generator is measured as a ratio of the number of mod-
potheses, strengthening convergence of results (Eisen-
ules developed using such tools divided by the total
hardt 1989).
number of modules in the application. Packaged soft-
To improve the internal validity of the analysis, sev-
ware is represented with a binary variable to indicate
eral criteria were used to select projects and applications
whether the software was purchased or developed in-
for inclusion in the study: size, recency, change in func-
house. To increase the validity of the development prac-
tionality, and similarity of programming language.
tices measures, two sources of information were used
Larger projects (i.e., those requiring more than one
as a cross-check: the software code itself and a ques-
work day to complete) were selected because factors
tionnaire completed by application managers.
affecting productivity on short, one-person projects can
Software complexity is assessed in terms of its compo-
be overwhelmed by individual skill differences (Banker
nent, coordinative, and dynamic dimensions. Data den-
et al. 1991, DeMarco 1982, Curtis 1981). Project recency
sity is measured by the number of data elements refer-
is important because personnel turnover and lack of
enced in the software, using Halstead’s N2 software sci-
documentation retention make accurate data collection
ence metric (Halstead 1977). This metric derives from a
impossible for older projects. The third criterion consid-
count of operands (data variables) in a program. Deci-
ered was whether the project modifies software func-
sion density is measured using McCabe’s cyclomatic
tionality; this improves homogeneity of the projects an-
complexity (McCabe 1976). McCabe’s metric counts the
alyzed, since projects such as package installations or
number of decision paths in the software. Decision vol-
conversions to new operating systems are excluded
atility refers to the number of decision paths that are
from the sample and are not compared with projects
dynamically altered at software execution time. It is es-
that modify functionality. The final criterion considered
timated by counting the number of dynamically exe-
was whether the software was written in a similar pro-
cuted subroutines invoked by the ‘‘CALL’’ command.
gramming language. All program code analyzed was
To control for program size, the complexity variables
written in COBOL. Therefore, the results are not con-
are normalized by dividing each by the total lines of
founded by the effects of multiple programming lan-
code in the programs modified by the project. For the
guages.
application model, the complexity variables are nor-
3.3. Construct Measurement, Reliability and malized by dividing each by the total lines of code in
Validity the application.
The theoretical models for maintenance performance Confirmatory factor analysis utilizing varimax rota-
and software complexity are operationalized as follows. tion (Johnson and Wichern 1992) and the Kaiser-Meyer-
Software enhancement project effort is measured for a Olkin index (1974) were employed to verify that the
cross-sectional set of completed projects by counting the complexity constructs loaded on orthogonal factors.
total number of labor hours logged to the projects. The While there is significant pairwise correlation between
study focuses on labor hours as the variable of interest, the data density and decision density measures, the

440 MANAGEMENT SCIENCE/Vol. 44, No. 4, April 1998

3b28 0008 Mp 440 Monday Apr 06 08:40 AM Man Sci (April) 0008
 BANKER, DAVIS, AND SLAUGHTER
Software Development Practices, Software Complexity, and Maintenance Performance

software complexity variables cannot be adequately and maintenance are linked, design decisions have
represented by a reduced number of factors. This sup- long-term maintenance effects that are difficult to re-
ports the discriminant validity of the software complex- verse, and there is little knowledge of the effects of de-
ity measures. Informal support for convergent validity sign choices:
of the empirical complexity constructs was obtained
When Maintenance gets systems from Development, there are
from interviews with maintenance personnel. often many outstanding problems. Maintenance has to still
Software functionality modified is assessed by the num- work on things to get the system to work. If there are problems,
Downloaded from informs.org by [193.146.32.73] on 24 April 2014, at 15:36 . For personal use only, all rights reserved.

ber of function points added, changed, or deleted by the we call Development, but Development’s ‘‘stuck’’ and ‘‘has no
project. Application size is measured by counting the time to work on it,’’ so they can’t often offer much assistance.
Really complex programs often come from Development. On-
number of application function points. Function points
line screens, for example, often do two or three functions in one
measure the number of unique inputs, outputs, logical screen . . . and Maintenance has to rewrite the screen into two
files, external interface files, and external queries in- programs. Certain people in Development do that constantly.
cluded in a software application (IFPUG 1993). The The manager wanted to get it done and approved it. (Interview
counts are weighted for difficulty depending upon fac- Transcript, Maintenance Programmer, February 1, 1993)
tors such as whether the application runs in a distrib-
uted environment, or whether the application is held to When we turn over systems to Maintenance, we don’t get to
see whether we made a good design choice. Usually there’s two
above average performance standards (Albrecht and
or three different ways to do things. But most people in Devel-
Gaffney 1983). Function points is a widely used mea- opment haven’t had Maintenance experience so they don’t
sure of software size (Perry 1986) and is considered a know which is better for Maintenance. (Interview Transcript,
reliable measure of delivered software superior to the February 15, 1993, Development Programmer)
alternative measure of software lines of code (Kemerer
1993). For this study, function point counts were ob- Although many development and maintenance
tained from the Retailer’s Quality Assurance team, programmers occupied adjacent cubicles, there ap-
which is independent of Development and Mainte- peared to be little communication between the groups.
nance, but reports directly to the Chief Information Of- In fact, there appeared to be some friction, especially
ficer. when new systems were transferred from Development
Application quality is measured by counting the num- to Maintenance:
ber of repair hours for the application. Repair hours There should be an evaluation of those who created the system
were obtained from company time-tracking systems in the first place. Downtime and abends (system failures) are
and cross-checked against a parallel, paper-based sys- important. But they’re not given to Development so they can
learn what was done. There’s no interest by Development once
tem that reported repair, user support, and preventive
the system’s been turned over. There’s a book of turnover stan-
maintenance hours for the applications. dards, but the last sentence is like . . . ‘‘this can be waived at
Project team experience was subjectively assessed by the discretion of the manager accepting the system.’’ And they
maintenance managers in response to a project data pressure the manager to accept the system . . . it’s political.
questionnaire. Experience was measured on a five-point (Interview Transcript, Maintenance Programmer, March 1,
1993)
scale corresponding to the percentage of programmers
on the project team who had worked with the applica- In one situation, an entire new application was re-
tion for three or more years. The scale was derived from written over a period of three years by a maintenance
an existing instrument used in prior empirical work team dedicated to redeveloping the code. A mainte-
(Banker et al. 1987, 1991). nance programmer described the interdependencies be-
tween Development and Maintenance:
4. Data Analysis and Results You know, data processing’s more mechanical now, like an
assembly-line. Everything’s so interrelated and there’s ripple
4.1. Interviews effects everywhere. We’re machinists, not artists . . . we need
Interviews with IS personnel provide support for cen- to have a good definition of where we want to go with (soft-
tral ideas motivating this study: software development ware) quality so Development and Maintenance can work

MANAGEMENT SCIENCE/Vol. 44, No. 4, April 1998 441

3b28 0008 Mp 441 Monday Apr 06 08:40 AM Man Sci (April) 0008
 BANKER, DAVIS, AND SLAUGHTER
Software Development Practices, Software Complexity, and Maintenance Performance

together. (Interview Transcript, Maintenance Programmer, enhancement projects or non-COBOL projects. Twenty-
February 1, 1993)
nine software enhancement projects were thus selected
Interview comments suggest the importance of un- for analysis. Table 1 presents a statistical profile of the
derstanding in more detail the link between develop- projects. The average software enhancement project re-
ment choices and maintenance effects. In the following quired 453 hours to complete, and added, changed, or
sections, the analysis of quantitative data on software deleted 143 function points. A correlation matrix for the
enhancement projects, software applications, and de- variables appears in Table 2.
Downloaded from informs.org by [193.146.32.73] on 24 April 2014, at 15:36 . For personal use only, all rights reserved.

sign practices provides insights into the precise nature A variety of specification checks were performed for
of the relationship between development practices and the estimated model to ensure that standard assump-
maintenance performance at the research site. tions were satisfied. The Shapiro-Wilk test for normality
of residuals in small samples (Shapiro and Wilk 1965)
4.2. Model 1: Software Maintenance Performance rejected the normality assumption at the 5 percent sig-
The effect of software complexity on enhancement pro- nificance level. A logarithmic transformation of the de-
ject effort is analyzed using project-level data to esti- pendent variable was indicated by the Box-Cox proce-
mate a multiple regression model that relates software dure (Box and Cox 1964) to correct for skewness. Spec-
enhancement project effort, software complexity, soft- ification checks were conducted after transforming to a
ware functionality, and other project characteristics: semi-log model. The Shapiro-Wilk test indicated that
Project Hours the normality assumption was not violated. Both Glej-
ser’s (1969) and White’s (1980) tests suggested that the
Å b0 / b1 (Data Density) homoscedasticity assumption was not violated for the
/ b2 (Decision Density) / b3 (Decision Volatility) revised model. Belsley-Kuh-Welsch (1980) collinearity
diagnostics indicated a highest condition number for
/ b4 (Project Function Points) the model of 19.68, within the recommended limit
/ b5 (Team Experience) (Greene 1993). Variance inflation factors for the inde-
pendent variables were all below 10, also suggesting
/ b6 (Application Repair Hours) that multicollinearity is not a problem (Neter et al.
1990).
/ b7 (Application Function Points) / e
Statistical results from one-tailed tests of the hypoth-
After discussions with IS staff concerning accurate eses are presented in Table 3. The results support the
project record retention, only projects completed within hypotheses that enhancement effort is positively related
a three-year time frame between January 1991 and De- to decision density and decision volatility. As expected,
cember 1993 were considered for inclusion in the study. enhancement effort is positively related to project size,
Of the 40 large projects completed during that time application repair hours, and application size, and is
frame, 11 were eliminated because they were either non- inversely related to team experience. The joint effect of

Table 1 Statistical Profile of Software Enhancement Projects

Variable Mean Std. Dev. Min Max Q1 Q2 Q3

Project Hours 453.0 541.6 48.0 2,450.6 92.0 265.0 573.5

Project Function Points 143 210 8 1,052 13 86 217
Application Function Points 3,105 1,475 1,319 5,355 1,847 2,640 4,876
Application Experience 3.0345 1.5232 1.0000 5.0000 2.0000 3.0000 5.0000
Repair Hours 989.1 698.8 35.75 2,828.5 433.0 851.0 1,329.0
Data Density 0.7624 0.2064 0.1228 1.1994 0.6559 0.7502 0.8734
Decision Density 0.0536 0.0242 0.0100 0.1190 0.0399 0.0472 0.0706
Decision Volatility 0.0109 0.0059 0.0000 0.0212 0.0061 0.0125 0.0149

442 MANAGEMENT SCIENCE/Vol. 44, No. 4, April 1998

3b28 0008 Mp 442 Monday Apr 06 08:40 AM Man Sci (April) 0008
 BANKER, DAVIS, AND SLAUGHTER
Software Development Practices, Software Complexity, and Maintenance Performance

Table 2 Correlation Matrix for Software Enhancement Projects

Project Application
Project Function Function Application Repair Data Decision Decision
Hours Points Points Experience Hours Density Density Volatility

Project Hours 1.0000

Project Function Points 0.7550* 1.0000
Application Function Points 0.0882 0.1057 1.0000
Downloaded from informs.org by [193.146.32.73] on 24 April 2014, at 15:36 . For personal use only, all rights reserved.

Application Experience 00.0969 0.1870 00.4778* 1.0000

Repair Hours 0.3011 0.0056 00.0699 00.2765 1.0000
Data Density 00.0222 00.0527 00.0246 0.0935 0.4046* 1.0000
Decision Density 0.1377 0.0684 00.0503 0.2412 0.2338 0.7188* 1.0000
Decision Volatility 0.0763 0.1671 00.1500 0.3183 00.1795 00.1518 00.0997 1.0000

* Indicates that correlation is statistically significant at the 5% level.

the three software complexity variables on enhance- is the high correlation between the data and decision
ment effort is also significant. density variables. To check this explanation, the model
The coefficient for data density is significantly nega- was estimated without the decision density variable.
tive, contrary to Hypothesis 1. We examined several al- Neither the sign nor significance of the data density
ternative explanations for this finding. One explanation variable changed, suggesting that collinearity with the

Table 3 Regression Results for Software Enhancement Model (t statistics in Parentheses)

Coefficient Basic Model Standardized Model Without Outliers Rank Regression

Variables (predicted sign) (n Å 29) (n Å 29) (n Å 27) (n Å 29)

Intercept b0 5.1992* 0.0000 5.1730* 2.5945

(6.984) (8.518) (0.690)
Data Density b1 (/) 02.7406* 00.5161* 02.0156* 00.2017**
(02.964) (02.964) (02.619) (01.410)
Decision Density b2 (/) 24.0894* 0.5321* 29.6446* 0.5454*
(3.176) (3.176) (3.989) (3.856)
Decision Volatility b3 (/) 49.1781* 0.2636* 37.7802* 0.0850
(2.179) (2.179) (2.069) (0.909)
Project Function Points b4 (/) 0.0032* 0.6188* 0.0054* 0.7353*
(5.156) (5.156) (5.647) (7.361)
Application Experience b5 (0) 00.1499** 00.2083** 00.2199* 00.3626*
(01.327) (01.327) (02.232) (02.841)
Repair Hours b6 (/) 0.0005* 0.2889* 0.00002 0.0053
(2.101) (2.101) (0.079) (0.056)
Application Function Points b7 (/) 0.0001 0.0659 00.00002 0.0202
(0.480) (0.480) (0.201) (0.192)
R2 – 0.7395 0.7395 0.8257 0.8535
Adjusted R 2 – 0.6526 0.6526 0.7615 0.8047
F test (Model) bi Å 0 for all i 8.515* 8.515* 12.861* 17.4822*
F test (Complexity) b1 Å b2 Å b3 Å 0 5.248* 5.248* 6.354* 6.4082*

* Indicates significance at 5% level.

** Indicates significance at 10% level.

MANAGEMENT SCIENCE/Vol. 44, No. 4, April 1998 443

3b28 0008 Mp 443 Monday Apr 06 08:40 AM Man Sci (April) 0008
 BANKER, DAVIS, AND SLAUGHTER
Software Development Practices, Software Complexity, and Maintenance Performance

decision density variable is not causing a shift in sign. 4.3. Model 2: Software Complexity
Another alternative is that data density is correlated The effect of software development practices on soft-
with an omitted variable. Data density was then re- ware complexity is assessed using application-level
gressed on several additional variables (including ap- data to estimate models relating software complexity
plication lines of code, project team skill, project team attributes with measures of development practices:
IS experience, and total lines of code modified in the
project). The regression was not significant, indicating Data Density
Downloaded from informs.org by [193.146.32.73] on 24 April 2014, at 15:36 . For personal use only, all rights reserved.

that data density was not related to any measured vari- Å g01 / g11 (Code Gen) / g21 (Package) / e1 ,
able omitted from the model. A third alternative is that
there is a causality problem in the model; however, the Decision Density
time precedence in the data should reduce this possi- Å g02 / g12 (Code Gen) / g22 (Package) / e2 ,
bility.
A potential explanation for the result that data Decision Volatility
density is associated with less project effort is that Å g03 / g13 (Code Gen) / g23 (Package) / e3 .
programs high in data density contain lower func-
tional complexity. Programs high in data density are Because the equations have identical explanatory vari-
in applications representing lower levels of infor- ables, ordinary least squares and generalized least
mation processing (Davis and Olson 1985, p. 7). The squares estimates are identical.
applications with the highest data density include Table 4 presents a statistical profile of the 23 COBOL
the accounting and basic financial transaction- applications included in the study. The average appli-
processing systems such as accounts receivable, gen- cation included 401,434 lines of code and 2,368 function
eral ledger, accounts payable, and payroll, as well as points. The total size of the portfolio analyzed was
interface systems. Such applications process vol- 9,232,973 lines of code and 54,470 function points. This
umes of data in a relatively simple manner and are represents about 65 percent of the company’s total ap-
less functionally sophisticated than systems like plication portfolio. A correlation matrix for key vari-
merchandise forecasting and planning, and may ables appears in Table 5.
thus be more easily modified. An interesting direc- Normality and homoscedasticity assumptions were
tion for further research would be to examine the satisfied for all three equations. The Box-Cox proce-
relationship between the levels of information pro- dure indicated that no transformations were neces-
cessing in the applications and the effort required for sary. Pearson partial correlations, condition numbers
maintaining them. for the models (highest of 3.76), and variance inflation
To assess the robustness of the estimated parame- factors (all less than 10) suggested that multicolli-
ters, a number of sensitivity analyses were conducted. nearity is not unduly influencing the estimates. Sta-
Belsley-Kuh-Welsch (1980) procedures led to the tistical results (Tables 6a through 6c) support the hy-
omission of two influential observations from the re- potheses that packaged software is associated with in-
gression. The sign and significance of the re-estimated creased data and decision density and with decreased
software complexity coefficients after omitting the in- decision volatility. Also supported are the hypotheses
fluential observations correspond to those in the orig- that use of the code generator is associated with re-
inal model (Table 3). An additional sensitivity check duced data and decision density and with increased
involved a rank regression to assess the robustness of decision volatility.
results to functional forms (Iman and Conover 1979). Sensitivity analyses included re-estimating the de-
The sign and significance of the complexity coeffi- cision density equation after deleting two influential
cients in the rank regression correspond to those in observations identified using the Belsley-Kuh-Welsch
the original model with the exception of the decision (1980) criteria (there were no influential outliers in
volatility variable whose coefficient was not signifi- the data density and decision volatility models). The
cant (Table 3). sign and significance of the development practices

444 MANAGEMENT SCIENCE/Vol. 44, No. 4, April 1998

3b28 0008 Mp 444 Monday Apr 06 08:40 AM Man Sci (April) 0008
 BANKER, DAVIS, AND SLAUGHTER
Software Development Practices, Software Complexity, and Maintenance Performance

Table 4 Statistical Profile of Software Applications

Variable Mean Std Dev Min Max Q1 Q2 Q3

Total Lines of Code 401,434 430,462 3,636 1,528,670 138,069 255,999 512,037
Proportion of Code Generator 0.2276 0.2521 0.0000 0.7351 0.0000 0.1021 0.4000
Application Function Points 2,368 1,693 273 5,482 814 1,847 3,704
Package 0.174 0.388 0.00 1.000 0.000 0.000 0.000
Data Density 0.7255 0.1191 0.5555 1.0050 0.6186 0.7122 0.8024
Downloaded from informs.org by [193.146.32.73] on 24 April 2014, at 15:36 . For personal use only, all rights reserved.

Decision Density 0.0515 0.0118 0.0357 0.0850 0.0441 0.0489 0.0579

Decision Volatility 0.0083 0.0049 0.0008 0.0160 0.0042 0.0078 0.0130

Table 5 Correlation Matrix for Software Applications

Proportion
Total Lines Application of Code Data Decision Decision
of Code Function Points Generator Package Density Density Volatility

Total Lines of Code 1.0000

Application Function Points 0.6132* 1.0000
Proportion of Code Generator 0.7069* 0.2541 1.0000
Package 00.1599 0.1660 00.4025 1.0000
Data Density 00.4179* 00.2698 00.6086* 0.5207* 1.0000
Decision Density 00.2991 00.1848 00.6103* 0.6192* 0.8133* 1.0000
Decision Volatility 0.5412* 0.2466 0.8216* 00.3864 00.3783 00.4733* 1.0000

* Indicates that correlation is statistically significant at the 5% level.

variables in the revised decision density regression The study examined the maintenance impact of two
correspond to those in the original model. Estimation key development practices at the research site: use of a
of rank regression models also confirmed that the sign code generator and packaged software. Software en-
and significance of the development practices vari- hancement effort was significantly related to software
ables in the original models are robust with the ex- complexity and was positively associated with the size
ception of the package variable, which is no longer of project functionality, application size, and applica-
significant at the 5 percent level in the decision den- tion repair hours, and inversely associated with project
sity model. team experience.
The use of a code generator was significantly related
to reduced data and decision density and increased de-
5. Discussion cision volatility. The overall impact of the code gener-
To examine the implications of software development ator on software enhancement effort is assessed using
practices for software maintenance performance, this the estimated coefficients for the code generator vari-
study developed an integrative model with software able, the individual software complexity variables, and
complexity as an intermediate variable linking design the enhancement effort variable (Table 7). Results in-
decisions to their downstream maintenance impacts. dicate that, ceteris paribus, an increase of 10 percent in
This model was empirically tested using data collected the proportion of code generator use is associated with
from a national mass merchandising retailer. The de- a 3.8 percent increase in software enhancement project
tailed results provide a number of interesting insights hours. This was a surprising result to software manag-
and suggest several conclusions. ers at the Retailer, but not to the maintenance

MANAGEMENT SCIENCE/Vol. 44, No. 4, April 1998 445

3b28 0008 Mp 445 Monday Apr 06 08:40 AM Man Sci (April) 0008
 BANKER, DAVIS, AND SLAUGHTER
Software Development Practices, Software Complexity, and Maintenance Performance

Table 6a Regression Results for Data Density Model (t Statistics in Parentheses)

Coefficient Rank
(Predicted Basic Model Standardized Model Without Outliers Regression
Variables Sign) (n Å 23) (n Å 23) (n Å 23) (n Å 23)

Intercept g01 0.7882* 0.0000 n/a 14.9095*

(21.028) (3.346)
Proportion of Code Generator g11 (0) 00.1228* 00.5023* n/a 0.06175*
Downloaded from informs.org by [193.146.32.73] on 24 April 2014, at 15:36 . For personal use only, all rights reserved.

(02.887) (02.887) (03.641)

Package g21 (/) 0.1002* 0.3261* n/a 0.3751**
(1.874) (1.874) (1.484)
R2 – 0.4855 0.4855 n/a 0.5605
Adjusted R 2 – 0.4341 0.4341 n/a 0.5166
F test (Model) g11 Å g21 Å 0 9.437* 9.437* n/a 12.753*

Table 6b Regression Results for Decision Density Model (t Statistics in Parentheses)

Standardized Rank
Coefficient Basic Model Model Without Outliers Regression
Variables (predicted sign) (n Å 23) (n Å 23) (n Å 21) (n Å 23)

Intercept g02 0.0573* 0.0000 0.0579* 18.143*

(17.518) (25.005) (4.419)
Proportion of Code Generator g12 (0) 00.0124* 00.5083* 00.0131* 00.7315*
(03.326) (03.326) (04.938) (04.68)
Package g22 (/) 0.0129* 0.4223* 0.0158* 0.2196
(2.763) (2.763) (3.868) (.943)
R2 – 0.6030 0.6030 0.7201 0.6269
Adjusted R 2 – 0.5633 0.5633 0.6890 0.5896
F test (Model) g12 Å g22 Å 0 15.191* 15.191* 23.158* 16.801*

Table 6c Regression Results for Decision Volatility Model (t Statistics in Parentheses)

Standardized Without Rank

Coefficient Basic Model Model Outliers Regression
Variables (predicted sign) (n Å 23) (n Å 23) (n Å 23) (n Å 23)

Intercept g03 0.00493* 0.0000 n/a 3.0180

(3.001) (0.735)
Proportion of Code Generator g13 (/) 0.00573* 0.5669* n/a 0.7944*
(3.075) (3.075) (5.084)
Package g23 (0) 00.00212 0.1668 n/a 00.0459
(0.905) (0.905) (00.197)
R2 – 0.4225 0.4225 n/a 0.6269
Adjusted R 2 – 0.3647 0.3647 n/a 0.5896
F test (Model) g13 Å g23 Å 0 7.315* 7.315* n/a 16.800*

* Indicates significance at 5% level.

** Indicates significance at 10% level.

446 MANAGEMENT SCIENCE/Vol. 44, No. 4, April 1998

3b28 0008 Mp 446 Monday Apr 06 08:40 AM Man Sci (April) 0008
 BANKER, DAVIS, AND SLAUGHTER
Software Development Practices, Software Complexity, and Maintenance Performance

Table 7 Calculation of Effects of Development Practices

ln Project CodeGen Package

i Complexity Hours (bi) (g1i) (g2i)

Estimated Parameter Coefficients from Tables 3 and 6

1 Data Density 02.7406 00.1228 0.1002

2 Decision Density 24.0894 00.0124 0.0129
Downloaded from informs.org by [193.146.32.73] on 24 April 2014, at 15:36 . For personal use only, all rights reserved.

3 Decision Volatility 49.1781 0.0057 00.0021

CodeGen Package
i Partial Effects of the Following: (bi * g1i) (bi * g2i)

Impact on Enhancement Project Effort

1 Data Density 0.33654 00.27460

2 Decision Density 00.29870 0.31075
3 Decision Volatility 0.28179 00.10327
Total [Å(ibigki]: 0.31963 00.06712
% Change [Å (exp(ibigki 0 1) * 100]: 37.66183% 06.49170%

programmers. Although the code generator creates inversely related to decision volatility. Overall, an in-
standardized routines that reduce data and decision crease in the use of packaged software is associated with
density, conditionally invoked routines that alter the a 6.5 percent decrease in software enhancement project
standard flow of program logic were embedded in the hours (Table 7). This result was surprising at first to
code to customize it to user requirements, increasing both the software managers and the maintenance
decision volatility and leading to lower software main- programmers. As one programmer stated,
tenance performance. Maintenance programmers indi- Most of our packages have really junk code . . . you know,
cated that it was difficult to work with the code gener- written in the most complicated way. I don’t think the vendors
ator and to make modifications because of the mix of care. It’s so much better if they’re written simply. (Interview
generated and custom code. In many cases, the code no Transcript, Maintenance Programmer, February 22, 1993)
longer matched the original application design in the
Further investigation revealed that the accounting
tool because the programmers had changed the gener-
and financial packages used by the Retailer are data and
ated code but not the design:
decision intensive, reflected in higher data and decision
Tools like (the code generator) solve old problems but create complexity. However, the packages are low in decision
new ones. They just shift the problems to Maintenance. The volatility because they are less integrated into the ap-
problem with (the code generator) is that most changes are to
plication portfolio and have fewer invoked subroutines.
the user (customized) logic. Then it’s hard to figure out the
logic paths in that stuff because it calls in routines from all over.
In addition, modifications to these packages tend to be
And then the compiles take longer, and the testing and debug- relatively simple, involving customization of printing
ging are more complicated. At first (the code generator) only routines and internal table values to accommodate the
had a screen painter, so you had to edit the program in Pan- Retailer’s unique codes, and thus require less mainte-
valet, and there was no validation except when you compiled nance effort.
it! Also, navigating through the tool is difficult. There are layers
and layers of menus, and you just want to make a change to
one or two lines of code. (Interview Transcript, Maintenance
Programmer, March 1, 1993)
6. Concluding Remarks
This study provides insight into how performance in
The use of purchased software was significantly as- software maintenance can be improved. From a contin-
sociated with increased data and decision density, and uous quality improvement perspective, the key idea is

MANAGEMENT SCIENCE/Vol. 44, No. 4, April 1998 447

3b28 0008 Mp 447 Monday Apr 06 08:40 AM Man Sci (April) 0008
 BANKER, DAVIS, AND SLAUGHTER
Software Development Practices, Software Complexity, and Maintenance Performance

that software development practices have long-term guy. Q.A. (Quality Assurance) has no upper level management
support. Programmers think management is out of touch—
consequences that are difficult and costly to reverse, and
they just do the best they can. You’ve got programmers making
therefore, to improve the software process, innovations
decisions on quality versus time. Everyone knows we need to
must focus on improving the efficacy of design and de- improve quality. It’s not finger pointing—it should be forward-
velopment procedures. The software industry has been direction pointing. [Interview Transcript, Development Pro-
plagued by the ‘‘silver bullet syndrome’’—the belief grammer, February 8, 1993] 1
that new tools and techniques will solve software prob-
Downloaded from informs.org by [193.146.32.73] on 24 April 2014, at 15:36 . For personal use only, all rights reserved.

lems, without investing the time and effort needed to

1
gain an understanding of the cause and effect relation- The authors thank the departmental editor, the associate editor, and
three anonymous reviewers for their valuable comments and sugges-
ships relating to the problems (Fenton et al. 1994). With-
tions. We gratefully acknowledge research support from the Quality
out this understanding, each new innovation, such as Leadership Center at the University of Minnesota. The cooperation
structured design, CASE tools, and object-oriented pro- and assistance of managers and staff at our data site was invaluable.
gramming, is adopted as the latest ‘‘silver bullet’’ and Helpful comments were provided by participants in research seminars
subsequently rejected as expectations are lowered, and at the University of British Columbia, Carnegie Mellon University,
Georgia State University, University of Minnesota, University of Pitts-
original problems persist, perhaps accompanied by new
burgh, and Stanford University.
problems. To that end, a critical element of this study
has involved collecting evidence on the maintenance References
performance effects of development practices to foster Albrecht, A. J. and J. Gaffney, ‘‘Software Function, Source Lines of
learning about the software process (Garvin 1993, Code, and Development Effort Prediction: A Software Science
Grady 1993). Validation,’’ IEEE Trans. on Software Engineering, SE-9, 6 (1983),
639–648.
In addition, software process innovations are primar-
ANSI/IEEE Standard 729, An American National Standard IEEE Stan-
ily directed toward improvement of development pro- dard Glossary of Software Engineering Terminology, 1983.
ductivity, when the majority of software life cycle costs Arthur, L. J., Software Evolution, John Wiley & Sons, Inc., New York,
are post-implementation (Swanson and Beath 1989). 1988.
Results from this study suggest that development pro- Banker, R. D., S. Datar, and C. F. Kemerer, ‘‘Factors Affecting Software
Maintenance Productivity: An Explanatory Study,’’ Proc. Eighth
ductivity tools do not have similar benefits for mainte-
International Conf. on Information Systems, ACM, New York, 1987,
nance, and that software maintenance concerns should
160–175.
play a larger role in the adoption of design and devel- , , and , ‘‘A Model to Evaluate Variables Impacting the
opment practices (Banker and Kemerer 1992). The IS Productivity of Software Maintenance Projects,’’ Management Sci.,
function is under increasing pressure to demonstrate 37, 1 (1991), 1–18.
productive performance and to contribute to the firm’s , , , and D. Zweig, ‘‘Software Complexity and Software
Maintenance Costs,’’ Comm. ACM, November, 36, 11 (1993), 81–94.
business objectives. Such pressures work against a long-
, , and D. Zweig, ‘‘Software Complexity and Maintainability,’’
term perspective, discouraging the investments neces- Proc. Tenth International Conf. on Information Systems, ACM, New
sary to measure, evaluate, and learn, and to make con- York, 1989, 247–255.
tinuous software process improvements. These senti- and C. F. Kemerer, ‘‘Performance Evaluation Metrics for Infor-
ments are eloquently summarized by a development mation Systems Development: A Principal-Agent Model,’’ Infor-
mation Systems Res., 3, 4 (1992), 379–400.
programmer at the research site in response to a ques-
Belsley, D. A., E. Kuh, and R. E. Welsch, Regression Diagnostics: Iden-
tion about software quality:
tifying Influential Data and Sources of Collinearity, Wiley, New York,
Yes, I think it’s important, but you need to prove it. Look at 1980.
Japan—they’re innovating. They’re taking the process and im- Boehm-Davis, D. A., R. W. Holt, and A. C. Schulz, ‘‘The Role of Pro-
proving it. The auto industry is a good example. They taught gram Structure in Software Maintenance,’’ International J. Man-
us how important it was. You can attach a dollar figure to this, Machine Studies, 36, 1 (1992), 21–63.
although the actual payback is kind of fuzzy . . . for example, Boulding, K. E., Economics as a Science, McGraw-Hill, New York, 1970.
if a 10 percent design fix upfront will save 90 percent rework Box, G. E. and D. R. Cox, ‘‘An Analysis of Transformations,’’ J. Royal
later. But people want immediate results. In IS, the standards Statistical Society B, 26 (1964), 211–243.
keep going up. It’s a frustrated department at every level. Brooks, F. P., ‘‘No Silver Bullet: Essence and Accidents of Software
You’ve got management. They always feel like they’re the bad Engineering,’’ Computer, April (1986), 10–19.

448 MANAGEMENT SCIENCE/Vol. 44, No. 4, April 1998

3b28 0008 Mp 448 Monday Apr 06 08:40 AM Man Sci (April) 0008
 BANKER, DAVIS, AND SLAUGHTER
Software Development Practices, Software Complexity, and Maintenance Performance

Campbell, D. J., ‘‘Task Complexity: A Review and Analysis,’’ Acad. Greene, W. H., Econometric Analysis, 2nd ed., Macmillan, New York,
Management Rev., 13, 1 (1988), 40–52. 1993.
Card, D. N., ‘‘Designing Software for Producibility,’’ J. Systems and Gremillion, L. L., ‘‘Determinants of Program Repair Maintenance Re-
Software, 17 (1992), 219–225. quirements,’’ Communications of the ACM, 27, 8 (1984), 826–832.
and R. L. Glass, Measuring Software Design Quality, Prentice Hall, Guimaraes, T., ‘‘Managing Application Program Maintenance Expen-
Englewood Cliffs, NJ, 1990. ditures,’’ Comm. ACM, 26, 10 (1983), 739–746.
Croxton, M., ‘‘Maintenance Still on IT Resume,’’ Software Magazine, 14, Hale, D. P. and D. A. Haworth, ‘‘Software Maintenance: A Profile of
6 (1994), 4–6. Past Empirical Research,’’ Proc. Fourth Conf. on Software Mainte-
Downloaded from informs.org by [193.146.32.73] on 24 April 2014, at 15:36 . For personal use only, all rights reserved.

Curtis, B., ‘‘Substantiating Programmer Variability,’’ IEEE Proceedings, nance, IEEE Computer Society Press, Washington, DC, 1988, 236–
69, 7 (1981), 846. 240.
, S. B. Sheppard, P. Milliman, M. A. Borst, and T. Love, ‘‘Measur- Halstead, M., Elements of Software Science, Elsevier North-Holland,
ing the Psychological Complexity of Software Maintenance Tasks New York, 1977.
with the Halstead and McCabe Metrics,’’ IEEE Trans. on Software IFPUG, Function Point Counting Practices Manual, International Function
Engineering, SE-5, 2 (1979), 96–104. Points User’s Group, J. Sprouls (Ed.) AT&T, Piscataway, NJ, 1993.
Davis, G., ‘‘To Buy, Build, or Customize?’’ Accounting Horizons, March Iman, R. L. and W. J. Conover, ‘‘The Use of the Rank Transform in
(1988), 101–103. Regression,’’ Technometrics, 21, 4 (1979), 499–509.
, R. Collins, M. Eierman, and W. Nance, ‘‘Productivity from In- Johnson, R. A. and D. W. Wichern, Applied Multivariate Statistical Anal-
formation Technology Investment in Knowledge Work,’’ in R. D. ysis, 3rd ed., Prentice-Hall, Englewood Cliffs, NJ, 1992.
Banker, R. J. Kauffman, and M. A. Mahmood (Eds.), Strategic In- Kaiser, H. F., ‘‘An Index of Factorial Simplicity,’’ Psychometrika, 39
formation Technology Management: Perspectives on Organizational (1974), 31–36.
Growth and Competitive Advantage, Idea Group Publishing, Harris- Kemerer, C., ‘‘Reliability of Function Points Measurement,’’ Comm.
burg, PA, 1993, 327–345. ACM, 36 (1993), 85–97.
and M. Olson, Management Information Systems: Conceptual Foun- , ‘‘Software Complexity and Software Maintenance: A Survey of
dations, Structure, and Development, McGraw-Hill, New York, Empirical Research,’’ Ann. Software Engineering, 1 (1995), 1–22.
1985. Kriebel, C. and A. Raviv, ‘‘An Economics Approach to Modeling the
DeMarco, T., Controlling Software Projects, Yourdon Press, New York, Productivity of Computer Systems,’’ Management Sci., 26, 3
1982. (1980), 297–311.
Eisenhardt, K. M., ‘‘Building Theories from Case Study Research,’’ Li, H. F. and W. K. Cheung, ‘‘An Empirical Study of Software Metrics,’’
Acad. Management Rev., 14, 4 (1989), 532–550. IEEE Trans. on Software Engineering, SE-13, 6 (1987), 697–708.
Everest, G. and M. Alanis, ‘‘Assessing User Experience with CASE Littman, D. C., J. Pinto, S. Letovsky, and E. Soloway, ‘‘Mental Models
Tools: An Exploratory Analysis,’’ Proc. 25th Hawaii International and Software Maintenance,’’ J. Systems and Software, 7 (1987),
Conf. on Systems Science, IEEE Computer Society Press, Los Ala- 341–355.
mitos, CA, January 1992. Locke, E. A. and G. P. Latham, A Theory of Goal-Setting and Task Per-
Fenton, N., S. L. Pfleeger, and R. L. Glass, ‘‘Science and Substance: A formance, Prentice-Hall, Englewood Cliffs, NJ, 1990.
Challenge to Software Engineers,’’ IEEE Software, 11, 4 (1994), 86– Lynch, R. K., ‘‘Implementing Packaged Application Software: Hidden
95. Costs and New Challenges,’’ Systems, Objectives, Solutions, 4
Fjeldstad, R. K. and W. T. Hamlen, ‘‘Application Program Mainte- (1984), 227–234.
nance Study—Report to Our Respondents,’’ in G. Parikh and H. McCabe, T. J., ‘‘A Complexity Measure,’’ IEEE Trans. on Software En-
Zvegintzov (Eds.), Tutorial on Software Maintenance, IEEE Com- gineering, SE-2, 4 (1976), 308–320.
puter Society Press, Silver Spring, MD, 1983. Martin, J. and C. McClure, ‘‘Buying Software Off the Rack: Packages
Garvin, D. A., ‘‘Building a Learning Organization,’’ Harvard Business Can Be the Solution to the Software Shortage,’’ Harvard Business
Rev., July–August (1993), 78–91. Rev., November–December (1983), 32–60.
Gibson, V. R. and J. A. Senn, ‘‘System Structure and Software Munson, J. C. and T. M. Khoshgoftaar, ‘‘The Dimensionality of Pro-
Maintenance Performance,’’ Comm. ACM, 32, 3 (1989), 347– gram Complexity,’’ Proc. International Conf. on Software Engineer-
358. ing, IEEE Computer Society Press, Washington, DC, 1989, 245–
Gill, G. K. and C. F. Kemerer, ‘‘Cyclomatic Complexity Density and 253.
Software Maintenance Productivity,’’ IEEE Transactions on Soft- Neter, J., W. Wasserman, and M. H. Kutner, Applied Linear Statistical
ware Engineering, 17, 12 (1991), 1284–1288. Models, 3rd ed., Irwin, Homewood, IL, 1990.
Glesjer, H., ‘‘A New Test for Heteroscedasticity,’’ J. American Statistical Nosek, J. T. and P. Palvia, ‘‘Software Maintenance Management:
Association (1969), 316–323. Changes in the Last Decade,’’ J. Software Maintenance, 2, 3 (1990),
Grady, R. B., ‘‘Practical Results from Measuring Software Quality,’’ 157–174.
Comm. ACM, 36, 11 (1993), 62–68. Olle, T. W., H. G. Sol, and A. A. Verrijn-Stuart, Eds., Information System
Grammas, G. W. and J. R. Klein, ‘‘Software Productivity as a Strategic Design Methodologies: A Comparative Review, North-Holland, Am-
Variable,’’ Interfaces, 15, 3 (1985), 116–126. sterdam, 1983.

MANAGEMENT SCIENCE/Vol. 44, No. 4, April 1998 449

3b28 0008 Mp 449 Monday Apr 06 08:40 AM Man Sci (April) 0008
 BANKER, DAVIS, AND SLAUGHTER
Software Development Practices, Software Complexity, and Maintenance Performance

Oman, P. W., C. R. Cook, and M. Nanja, ‘‘Effects of Programming Stabell, C., ‘‘Office Productivity: A Microeconomic Framework for
Experience in Debugging Semantic Errors,’’ J. Systems and Soft- Empirical Research,’’ Office Technology and People, 1, 1 (1982),
ware, 9 (1989), 192–207. 91–106.
Pennington, N., ‘‘Stimulus Structures and Mental Representations in Stamps, D., ‘‘CASE: Cranking out Productivity,’’ Datamation, July 1
Expert Comprehension of Computer Programs,’’ Cognitive Psy- (1987), 55–58.
chology, 19 (1987), 295–341. Swanson, E. B. and C. M. Beath, Maintaining Information Systems in
Perry, W. E., ‘‘The Best Data Processing Measures,’’ System Develop- Organizations, John Wiley and Sons, New York, 1989.
ment, 6, 6 (1986), 4–6. Vessey, I., ‘‘Toward a Theory of Computer Program Bugs: An
Downloaded from informs.org by [193.146.32.73] on 24 April 2014, at 15:36 . For personal use only, all rights reserved.

Ramanujan, S. and R. B. Cooper, ‘‘A Human Information Processing Empirical Test,’’ International J. Man-Machine Studies, 30, 3
Approach to Software Maintenance,’’ OMEGA, 22 (1994), 185– (1989).
203. Weyuker, E. J., ‘‘Evaluating Software Complexity Measures,’’ IEEE
Schneidewind, N. F., ‘‘The State of Software Maintenance,’’ IEEE Trans. on Software Engineering, 14, 9 (1988), 1357–1365.
Trans. on Software Engineering, SE-13, 3 (1987), 303–310. White, H., ‘‘A Heteroscedasticity-Consistent Covariance Matrix Esti-
Senge, P. M., The Fifth Discipline: The Art and Practice of the Learning mator and a Direct Test for Heteroscedasticity,’’ Econometrica, 48
Organization, Doubleday, New York, 1992. (1980), 817–838.
Shapiro, S. S. and M. B. Wilk, ‘‘An Analysis of Variance Test for Nor- Wood, R. E., ‘‘Task Complexity: Definition of a Construct,’’ Organ-
mality,’’ Biometrika, 52 (1965), 591–612. izational Behavior and Human Decision Processes, 31 (1986), 60–
Shen, V. Y., T. J. Yu, S. M. Thebaut, and L. R. Paulsen, ‘‘Identifying 82.
Error-Prone Software—An Empirical Study,’’ IEEE Trans. on Soft- , A. J. Mento, and E. A. Locke, ‘‘Task Complexity as a Moderator
ware Engineering, SE-11, 4 (1985), 317–323. of Goal Effects: A Meta-Analysis,’’ J. Applied Psychology, 72, 3
Shneiderman, B., Software Psychology: Human Factors in Computer and (1987), 416–425.
Information Systems, Winthrop Publishers, Inc., Cambridge, MA, Zuse, H., Software Complexity: Measures and Methods, de Gruyter, Am-
1980. sterdam, 1990.
Simon, H. A., The Sciences of the Artificial, 2nd ed., The MIT Press, Zvegintzov, N., Software Maintenance News, 6, 8 (1988).
Cambridge, MA, 1981. , ‘‘Immortal Software,’’ Datamation, June (1984), 170–180.

Accepted by John C. Henderson; received April 10, 1996. This paper has been with the authors 4 months for 1 revision.

450 MANAGEMENT SCIENCE/Vol. 44, No. 4, April 1998

3b28 0008 Mp 450 Monday Apr 06 08:40 AM Man Sci (April) 0008