i HlliPiiil
m
^060
UPP ^BlE!;
ob^^oso
l
ifii
i
,:i;'v;;i;.i;i',ii;yi:!:
;i
DLv^ar
ALFRED
P.
WORKING PAPER
SLOAN SCHOOL OF MANAGEMENT
The Changing Role
of the User
in the Deveiop.Ti^^nt of Application Scftr-^are
Eradlev A. Feld
WT#
3152-90-BPS
August 1990
MASSACHUSETTS
INSTITUTE OF TECHNOLOGY
50 MEMORIAL DRIVE
CAMBRIDGE, MASSACHUSETTS 02139
trv'^'Sf-
^ OCT
23
1990
The Changing Role
of the User
in the Developm^^nt of Application Scft-^are
Bradley A. Feld
WT#
3152-90-BPS
August 1990
Abstract
In seeking to better understand the sources of innovation, researchers
investigated the division of labor
new
between user and manufacturer
development of
products. Specifically, the "partitioning of tasks" between user and manufacturer has
drawn
attention.
In this paper.
I
application software.
explore the changing role of the user in the development of
I
argue that responsibility for application development
from generic manufacturers of software
given this
transfer
tools
in the
have
shift,
them
an
to the users of the software.
efficient division of labor entails
to the users.
The user then develops
manufacturers
his or her
own
I
is
shifting
hypothesize that,
who develop
"tools"
and
applications using the
developed by the manufacturer.
I
carried out a pilot study
on the actual partitioning of
tasks
between the user of
application software and the specialist developer of the software (the manufacturer). In
this study.
I
investigated several software projects undertaken by a single custom software
firm for three clients seeking application software to automate aspects of their businesses.
Finally,
I
discuss several trends in software technology that could arise
shift of responsibility to the user.
from
this
ongoing
The Changing Role
in the
of the User
Development of Application Software
Introduction^
1
Although most software applications are currently developed by programmers,
innovations in software programming tools and user-friendly methods to link these tools
increasingly provide users
applications
more
who
efficiently
are not
and cost
programmers with the
effectively.
ability to
develop their own
These innovations are
in the
process of
transforming the way businesses and individuals approach application software
development.
Consider the development of a financial model for forecasting cash flow.
ago, the user
was required
assume the task of writing the program
COBOL or
BASIC.
If
the user
program, he would have
problem
to specify the
in a
to a
piogrammer, who would then
complex programming language such as
needed any changes made
to interrupt his
A decade
work and
try to
programmer, who would then take the necessary steps
after he
began using the
describe his needs to the
to incorporate the
program. Today, a user can implement her financial model directly
in a
changes into the
spreadsheet
program. She controls the entire development cycle according to her specific needs and
can quickly and freely make any necessary changes to the program as she works.
The
current evolution of software development tools appears to be shifting the
responsibility for application
programmer)
development from a
to the user of the software.
specialist
developer of software (the
New programming
environments for developing
application software (such as fourth-generation and object-oriented languages) are
appearing that not only dramatically decrease the cost of developing application software
1.
1
would
paper.
like to
thank
Enc von Hippel and David
Jilk for their stimulating
and
insightful contributions to the
work contained
in this
and increase the value of the software
her
own
applications.
division of labor
to the user, but also enable the user to
The impact of this trend
will, I believe,
lead to a new,
I
partitioning of application
on the implications
overall
for
programming
tasks
improved practice.
this subject (section 2).
specialist
programmer
--
I
I first
summarize some
often employed by a software "manufacturing" firm
partitioned between users and
in
3).
Next,
I
programmers of software and the
(section 4). In this study,
I
--
in the
discuss a pilot study that
I
which software development tasks are
information that affects application development
clients
literature that exists
then turn to a brief history of the roles of the end user
conducted to explore the different ways
developed for new
on the actual
between the user and the manufacturer and
development of application software (section
programmer
effective
explore the changing role of the user in the development of
application software and seek to establish an empirical basis for research
and
more
his or
between the developer and the user of software.
In this paper,
concerning
develop
is
efficiency with
which
transferred between user and
investigated three "first-of-kind" projects that
by a custom software company.^
I
examined various
were
qualities of
the information passed back and forth across organizational boundaries such as the
initiator of the request for
change (user or manufacturer), the granularity (chunks
vs.
items) of the messages transferred across organizational boundaries, the completeness or
incompleteness of messages transferred, and the content of users' requests (new features
vs. bugs).
Finally,
I
discuss
some trends
impact on the role of the user
2,
1
in the
I
have observed that
will increasingly
have an
development of application software (section
define application software as software developed for a specific user need. This
is
often referred to as "custom software
5).
'
2
The Literature
Various researchers have examined the division of labor between the user and
manufacturer
in the
innovation process.
Von Hippel
explored the relationship between
user and manufacturer by examining the sources of innovation (von Hippel 1988) and the
implications of task partitioning (von Hippel 1989).
interdependencies
among
tasks can be predicted
He
found that problem-solving
and then managed by either adjusting the
boundaries between tasks or reducing the barrier to problem-solving interactions across
More
boundaries.
recently, he discussed the effects of
what he terms
He
locus of problem-solving and innovation (von Hippel 1990).
data nejuc
to
move
t
u-; problcr.i-'
to other sites.
He
)!• i.
^ h?s "sticky" qualities that
hypothesized that
related problem-solving activity must
move
"if
to
mak"
an economy, other things being equal,
on only one locus of
sticky data..." (von
and among
to design
is
found that much of the
then: difn
.uit o;
ior> '.o:tly
loci
of sticky data
- perhaps
Von Hippel proposes
that
"it
problems so that problem-solving draws
Hippel 1990).
A number of other researchers have investigated
process
on the
data needed by a problem-solver are sticky,
repeatedly as problem-solving proceeds" (von Hippel 1990).
is
"sticky data"
organized and in what ways and
how
how
effectively
it
the software development
incorporates user and
manufacturer input. These studies have been concerned primarily with partitioning of
tasks in technical organizations. Salaway (1987) suggests that interactions
of a
team occur
at the intersection of user
among members
knowledge and designer knowledge. Henderson
and Lee (1989) found that during the development of an information system, designers
(software developers) were expected to build the system, but
(users)
were expected
to supply relevant business
domain representatives
knowledge and user input
to the
designers throughout the process. Finally, Orlikowski (1989) examined the changing
relationship
observed a
between user and developer
shift in the division
in the
development of information systems and
of labor between functional developers and technical
developers in a custom software organization following the introduction of computer-aided
(CASE)
software engineering
tools. All of these
substantial transfer of information
the
examples indicate that there
is
a
between software user and software developer during
development of application software.
3 Roles of the
Programmer and
The software
programming
industry
tasks:
The
is
the
End User
in the
Development of Software
being transformed by an increasing separation of
creation of application-generating programs (a "tool") and the
development of application software (an "application") are no longer a
single task
controlled by the programmer, as they once were.
In the 1960's,
tasks.
programmers using languages such
Even when the
programmer needed
distinction
between a
to build a tool
as
Assembly handled
and an "application" did
"tool"
were the same
skills
needed
to
all
exist,
software
the skills a
manipulate the tool to
create an application.
Over
time,
programmers realized
that their
work could be facihtated by the design of
reusable, self-contained modules. These modules, or tools,
became fundamental
components of newer programming languages. While early programming languages such
as
Assembly contained no
some
built-in,
tools, later
as
COBOL included
although limited, tools for developing input screens and reports. Current
programming languages (such
3.
programming languages such
as Focus, Dataflex, or Clarion^) contain
numerous
Focus, Dataflex. and Clanon are products of Information Builders. Data Access Corporation, and Clarion Software
respectively.
tools but
Company,
have added simple "user-friendly" methods to link these modules. For example, a
programmer using an
"object-oriented"^
programming language such
a "window" on the computer screen that behaves like a text editor.
as Actor^ can create
A decade
ago, this
operation would have taken thousands of lines of programming code written by an expert
programmer; today,
it
takes one line of
At the same time, advances
in the
programming code written by a
user.
power and speed of computer hardware have
permitted software programs to use larger self-contained modules A-ithout diminishing the
performance of the software. As computing power becomes
modules have become more complex without having a
li.e
less expensive,
software
on the performance of
visible effect
arplicaticn.
Together with
this
trend toward increased computing power, trends toward
self-contained .nodules and easy, user-friendly
automated tasks
that previously could only be
have enabled the user increasingly to program
methods
to link these
performed by
his or
her
modules have
specialist
own
programmers and
applications. Today, a user
can take various self-contained modules originally developed by a specialist programmer
and
link or reconfigure
them by means of "macros"" such
as those within Lx)tus 1-2-?.'
example, the financial spreadsheet forecasting cash flows that was discussed
For
in the
introduction might have been implemented through a Lotus 1-2-3 macro. In this case, the
macro (created by
the user) only runs within the context of a
program (Lotus
1-2-3).
Consequently, the program, created by a specialist programmer working for Lotus
4.
For
5.
Actor
a
good descnption of objcci-onenied programming, sec the
IS
a product of the
articles
A macro is a "program wthin a program" comprised of a senes of
can assemble to act as an application to solve a specific need
6.
7.
Lotus 1-2-3
IS
by cither Wegner (1989) or
Meng
(1990).
Whitewater Group
a spreadsheet
commands or
program from Lotus Development Corporation.
keystrokes specific to a sofrn-are program that the user
Corporation,
is
the application generator while the macro, developed by the user,
The
application.
pilot study discussed
below seeks
to take a first step
is
the
toward understanding
the impact of such shifts.
4 Pilot Study
4.1
Approach
My goal
in this study
was
to understand
how
application software development
partitioned between the end user and the software developer
transferred
--
or not transferred
--
their
specialist
clearly,
I
have elected to study situations in
programmers attempting
needs were employed by different firms. Specifically,
improvements
is
between these two during the course of software
development. In order to see such transfers
which end users and the
and how information
is
in the application software
to develop software to serve
I
studied the sources of 516
developed for three
clients ("users")
by a single
custom software application company ("software manufacturer").
The custom software firm
I
elected to study has been in business for five years and
has developed over 30 personal computer-based custom software apphcations for a wide
variety of businesses. In the process, the firm also created
process tools and gained a significant
numerous software development
amount of know-how based around a popular
fourth-generation language called Clarion. ^
Some sample
systems the firm has developed
include software for group medical practices, medical laboratory billing, venture capital
portfolio
management,
legal billing, insurance claim processing, real estate
analysis, rental store point-of-sale,
8.
and international accounting.
Qarion Professional Developer. Clarion Software Company, Pompano Beach, FL.
investment
Because of the way the software development firm approached custom software
development, a rich set of contemporaneous data was available for study. Using a
methodology similar
an
initial, partial
to rapid prototyping," the
custom software company quickly generates
solution to the client's problem and develops a custom application. TTie
client starts to use this software
and then makes
specific requests for changes.
software firm responds and through these interactions the
initial
solution
is
The
greatly
elaborated and improved over time through a series of "revisions" to the software issued as
software updates to the client. At the start of a client relationship, software revisions
be shipped to the
(.eciine
Xc.
client as often as every
may
two weeks. After a year, the frequency may
perhaps one revision eve'^ two monihs.
To ensure
that the user
the start of the study,
I
and manufacturer databases were
decided
tc focus
projects in industries in which the
on
distinct
"first-of-kind" software
development p-ojects
custom software firm was working
first-of-kind project, the software firm
had no
significant
from each other
at
--
for the first time. In a
knowledge of the
client's field of
business and the client had not previously been involved in a custom software project.
Each of the two databases (user and manufacturer) was,
development
The choice
project, in a different organization
to study first-of-kind projects
and
at least at the start of the
at a geographically distinct location.
was based on the observation
that,
over time, the
software development firm inevitably learns something about the fields of business of
clients, resulting in
a transfer of
some of
its
the user's database to the manufacturer. Also, the
m
which the programmer inlemcw-s the user, gets some information about
Rapid proiotyping is a softw.-arc development methodology
the application to be developed, and creates a prolotj-pe. ITic user then plays »nth the protot\pe and gives the manufacturer feedback,
which causes the manufacturer to develop another, niore refined protot\-pe. ITiis cycle continues until the user has a system that satisfies
9.
his
requirements
8
client learns
transfer of
something about the custom sofr^-are development process, resulting
some of the manufacturer's database
where
projects
this
to the user.
I
specifically
in
a
looked for
exchange of knowledge had not yet occurred.
The software company
I
studied was working
categorized these ten on the basis
of: (1)
on ten
first-of-kind projects.
I
then
the client's expertise regarding the particular
business problem he wanted the software to address, and (2) the client's understanding of
custom software.
I
classified the clients as either "high" or "low" for
both of these
characteristics.
I
determined how the projects were
classified with respect to these
two characteristics
by interviewing the principals or project leaders of each of the ten first-of-kind clients and
asking
them questions about
the business problem they
wanted
to
automate.
described his business problem as "confusing (to him)" or said something like
to
work
in the business office before, but
problem
in
my
Conversely,
if
if
business,"
I
classified his
I
have to learn about
it
in
order to
If
the client
"I
never had
fix this
understanding of the business problem as low.
the client clearly described the business
problem he wanted
to
automate, or
people within the client organization stated things such as "the boss really understands
how
this
If
organization runs,"
I
classified his
understanding of the business problem as high.
the client could only articulate his need for software to "cut
I
software. If the client
was already using software
problem, or
if
the client displayed
system being considered,
I
the work" or
having a low understanding of custom
to "reduce personnel,"
classified the firm as
down on
to analyze a
some understanding
component of his business
of the software and the computer
categorized his understanding of custom software as high.
After differentiating the ten first-of-kind projects on the basis of these vao
characteristics,
(portfolio
practice.
I
selected three to study over a two-year period: a venture capital firm
management), an insurance claims processing
firm,
and a group medical
10
Each request
software
company
for a
change was an individual item recorded by a
(usually a
programmer or
the project manager).
I
member
of the
identified a total of
5 16 requests affecting the three projects.
Each
revision consisted of a set of specific changes to the existing functions of the
application software and resulted from interactions between the user
(see Figure
firm.
1
for
an example from the study).
I
had access
to the
and the manufacturer
68 revisions issued by the
Table 2 shows the number of requests and the number of revisions for each of the
three projects.
PORTFOLIO MANAGER
VERSION 1.65
01/12/89
New Features
A new trade type, "INCOME" has been added to represent income from interest
1) Income from securities.
Transactions for these trades must have a 'delta' of 0, and the amount of income from
and dividends.
securities and total proceeds colunns.
The extra company information has a new field, 'Lead
filtered to include companies from one Lead VC only, or
2)
VC.
it
The portfolio summary report can be
can be printed as normal.
Enhancements
1) The Cost Analysis report now has Total Value and Difference coluins,
column.
2) The Trade Log reports (Investment,
in
addition to the Total Cost
Divestiture, etc.) now SLirmarize quarterly totals.
3) The Cost Analysis and Trade Log reports no longer print unnecessary zeroes on the right side of the
reports.
4) Multiple
comi tments
for the same security at different prices are now handled properly.
Bugs Fixed
1)
The Trade Log reports did not always clear the rightmost colims.
2) A nunber of potential
Figure
I
network bugs were found and corrected.
1:
Sample of a Revision
for the
Venture Capital Project
then sought to examine various qualities of the information transferred between the
client firm
and the software firm during the course of application development. To do
this,
11
Project
12
At the beginning of each
project,
two
rich, distinct
databases existed: the
client's
understanding of his business problem and the software company's understanding of the
custom software development process. Recall that
The software company had no
specific
all
three projects were first-of-kind.
knowledge about the application they were about
to
develop before the project began and the client had not previously been involved in a
custom software
in
project.
Each of the two databases (user and manufacturer) was
initially
a separate organization and at a geographically distinct location.
Following are
my
findings for the three projects
I
studied with regard to the initiator
of the request (user or manufacturer), the granularity (chunks vs. items) of the messages
transferred across the organizational boundaries, the completeness or incompleteness of
the messages transferred, and the content of user requests
4.2.1 Initiator of
Remember
that
my
goal in this study was to understand
- when two
organizations. Consequently,
manufacturer was
I
When
vs. bugs).
Request
partitioned between end user and software developer and
or not transferred
(new features
how
software development
how information
is
transferred
is
-
very different, rich databases are each held in different
it
was important
to
determine whether the user or the
initiating the requests for changes.
used the written records of the firm to determine the initiator of each request.
the initiator of the request was unclear,
I
interviewed the programmer
the request to determine the source of the request.
requests versus manufacturer-initiated requests
is
The breakdown
as follows:
who recorded
of user-initiated
13
Project
14
4.2.2
Granularity of the Messages Transferred
I
identified
two
levels of granularity
distinguished on the basis of the
amount of work involved
firm in implementing the request.
usually represents a significant
a "chunk" and an "item"
--
I
different tasks in order to
would have
to write
classified as a
implement the request. In
new
feature that
define an "item" as a
is:
"Implement the
to
perform a number of
this specific case, the
perform several
to
chunk
programmer
a request that requires the
program code
I
development
change to an already implemented chunk.
report, (2) search through the investment database
lO
for the software
amount of software development.
For example, a request that would be
is
that can be
define a "chunk" as a request for a
specific request that usually represents a
investment report." This
--
tasks: (1)
prograrmner
format the investment
and perform the calculations necessary
generate the appropriate output, and (3) generate the appropriate output. In a language
such as Clarion, this would require as
to a
day to write,
test,
many
as
one hundred
investment report two characters wider." In
in
order to implement the request
Clarion, this
would require a change
minutes to write,
test,
code that could take up
and debug.
A request that would be classified as an item
one task
lines of
to
one
"Make
is:
this case, the
--
the total
programmer only has
that of widening a field
line of the
column on the
to
perform
on the report. In
program and would take
fifteen
and debug.
Table 4 shows the breakdown of chunks and items
I
observed in the sample.
Interestingly, the vast majority of requests are for specific items. In all three projects, there
was roughly the same percentage of chunks (20%) and items (80%). This indicates
that the
15
Project
16
4.23 Completeness of the Messages Transferred
and manufacturer databases had
In each project, both user
to first generate
is
client
in
order
a significant advantage to be gained by efficiently partitioning
development tasks and by concentrating problem-solving
I
be drawn upon
and then solve each change request. Von Hippel (1989, 1990) has
suggested that there
in this study
to
in a single locus.
Consequently,
investigated whether (1) the rich data of each side, the software firm and the
who were
in different loci,
were
in
any substantial way transferred to the other side
so that problem-solving could proceed in one locus, or (2) whether the data remained
where they were and only requests
content
- moved between
for specific actions
-
stripped of any rich database
the two loci during the software development work, or (3)
something "in-between" took place,
e.g.,
the rich data
were transferred from manufacturer
to user in certain cases.
Evidence for the
interactions
you
all
first
between the
pattern, the transfer of rich data
client
and software firm
in
which
between
loci,
(a) the client said, "Let us tell
about our business so that you can develop a software package for
us about
how you
write software so that
"Let's get together
we can
figure out
would be
us,"
or (b) "Teach
what we need from you," or
and learn about each other so that we can do
(c)
this project jointly."
A series of discrete client-software firm interactions where the data remained where
they were and only requests for specific actions
evidence for the second pattern.
specific requests
-
in effect,
"Do
request or related reasoning.
specific responses
-
in effect.
On
On
this"
moved between
the client side,
- devoid
we might
did this"
-
would be
expect to see extremely
of user data regarding the context of the
the software firm side,
"We
the two loci
we might
expect to see very
also devoid of information regarding the
context or any explanation of the reasoning used to develop the particular response.
17
Evidence for the
third pattern,
where something "in-between" took place, would be a
combination of collaborative work between the user and manufacturer and specific
requests from either the user or manufacturer. For example, the user and manufacturer
might begin the project with a series of meetings to define the project. Then, the user
would
issue specific requests to the manufacturer during the life of the project. Finally,
periodic "working sessions" would be held by the user and manufacturer to check the
progress of the project and to reestablish priorities.
Interestingly, in all three projects
I
found that virtually
and forth between user and manufacturer were
th/'f"
nature
--
all
of the data passing back
for specific requests
--
essentially of a
thereby providing support for the second pattern noted above.
that the requests fell into
unambiguous enough
two categories:
(1) the initial
to al'ow the software firm to
information; or (2) the "Do
this"
"Do
this"
I
"Do
observed
request was complete and
implement the request without further
request needed further amplification before
it
could be
implemented.
Typical unambiguous requests from the client (in this case, the venture capital
column
company) would
be: "The trade log does not always clear rightmost
"Where you now
print 'share' in the output reports, print 'shares' instead."
company would make
effectively saying,
An
"Do
this"
should" or,
The software
the requested change and issue another release of the software,
"The software now does what you asked us
example of a "Do
capital project was,
-- it
this"
for."
request requiring further amplification in the venture
"Use percentage of cost method for revaluation." In the case where the
request required further amplification, the software
company was only concerned
with collecting the information needed to do what the client had requested
--
not with
evaluating the merit or validity or broader context of the request. In the above example.
18
the software
company
was a better solution
like,
"How would you
understand
I
how
to
did not investigate cost valuation equations in order to see
to this particular request. Instead the
if
there
programmer asked questions
calculate the percentage of cost for a revaluation?" in order to
implement the request.
also found that a request for further amplification
than for items, as in Table
Project
6.
is
much more
likely for
chunks
19
Hypothetically,
it is
possible for the manufacturer to learn the user's business and mix
the two databases. But, according to the interviews
The manufacturer
obtains
more information so
I
conducted,
this is
that he can satisfy the
not what happens.
"Do
this" requests,
but he does not necessarily understand the user's database.
In the case of the venture capital client, the users involved understood
PC-based
software and were often able to simulate what they wanted in terms of functions before
making a "Do
familiar with
this"
request of the software development firm.
some programming
tools,
When
the user
is
already
she does a better job of framing the problem for the
manufacturer. At the venture capital company, the user understood programming well
enough
to be able to prototype the
problem
partitioned the problem and transmitted
in
"Do
Lotus
this"
1-2-3.
Consequently, the user
requests that were clear and actionable
by the remotely located manufacturer.
At the venture
case, their
capital
company, the users also understood
knowledge of the capability of the software firm was
their business well. In this
sufficient to allow effective
interaction by both the user and the manufacturer at arm's length. Consequently, neither
firm had to transfer any rich data to the other side to have an effective interaction
regarding changes to the software.
In the case of the insurance claims processing
company, the
client
understood
his
business reasonably well, but did not understand the software development process.
client also
had a good manual system
the software firm studied the
statements
to the
it
needed
manufacturer
in
place that needed to be automated. Consequently,
manual system
in
to proceed. In this case,
at the
The
order to derive the series of "Do
some
beginning of the project.
rich data
this"
was transferred from the user
20
In the case of the medical practice, the client did not understand the benefit of
custom software and could not transfer either specific requests or an understanding of
database to the remotely located software development firm. In addition, the
understanding of
its
business problem was low. Specifically, the existing
its
client's
manual
procedures the firm wanted to automate were poorly understood by the user. Therefore a
representative of the software development firm ultimately had to travel to the client site
and work there
to effect this
communication between user and manufacturer. While
however, he did not collect a rich understanding of the user database and transfer
manufacturer. Instead, he concentrated on "understanding what
were supposed
we
it
there,
to the
(the manufacturer)
to do."
Finally, note that in
none of the cases were software development
tools transferred to
the user site so that the user could modify the software provided by the manufacturer. In
fact, it
was the policy of the software company not
to transfer such tools to the user so as to
retain a proprietary advantage over other developers of
4.2.4
Content of User Requests:
I
Features
vs.
Bugs
observed that 455 of the 516 requests were transmitted from the user
manufacturer
tasks
New
custom software.
site.
Von Hippel
site to the
(1989) has suggested that the traditional partitioning of
between the manufacturer and
user,
where users have needs and manufacturers have
the task of assessing these needs and developing a responsive product, often raises
significant
problems for innovative projects because of the high interdependency of
problem-solving. Consequently, in this study,
I
explored whether problems crossed back
and forth across the boundary between the user and the manufacturer.
21
Because the
rich user
and manufacturer databases had been kept separate by the
design of this study, the different types of requests by the user could in large part be further
examined and categorized.
(2) bugs,
and
New
I
divided these requests into three categories: (1)
features
were requests by the user
program performing new
either logical extensions of previous
for
changes to the software program that
These new features were
functions.
work
that
had been done or
distinct
automated processes that had not been previously automated.
feature request from the venture capital project
New features
logs."
coulo cither
bi^
one programm'ng
task,
below
it
that the manufacturer
different
totals
of a
feature required
If
it
new
on the trade
more
required only
had implemented that did not work
from requests that were poorly defined by the user,
example of a bug from the venture
liquidation schedule to print the
capital project
is
classified
program simply did not work. An
"Transactions out of order cause the
wrong information."
Specification errors were requests by the user that
made
new
was considered a chunk.
as "specification errors." In the case of bugs, the
cases, the user
a
new "modules"
An example
"Summarize quarterly
If
typically
was considered an item.
it
Bugs were functions
These are
is
a "chunk" or an "item."
than one programming task to implement,
correctly.
features,
(3) specification errors.
resulted in the
that
new
a request that,
were poorly defined. In these
when implemented by
the manufacturer,
prompted
the
user to revise the original request. While these requests were not actually bugs, they are
clearly distinct
The
follows:
from new
features.
classification of user requests into
new
features, bugs,
and specification errors
?'»
Project
23
who were new
users
on the
to the topic area in
each case, could not suggest a useful new function to the
basis of problem-solving carried out at the
consistent with the observation that most of the
manufacturer
site.
This
is
manufaaurer suggestions are very
technical in nature and relate specifically to the performance of the software.
43 Summan
of Findings
In this pilot study,
I
examined various characteristics of the information transfer that
took place between the end user and the software developer
application development projects.
I
found that
passing back and forth beivveen user an
this" nature.
I
\
in three first-of-kind software
in all three projects
manufacture/ were for
obser\'ed that these requests
fell
into
most of the data
specific re'uests of a
two categories:
(1) the initial
"Do
"Do
this"
request was complete and unambiguous enough to allow the software firm to imp'ement
the request without further information; or (2) the 'Do this" request
needed further amplification before
it
was incomplete and
could be implemented. In addition, the request for
further amplification was always initiated by the manufacturer.
I
also found that
most requests
for changes
manufacturer (12%). The user requests were
all
came from
the user
(88%) rather than
the
based on specific information contained
within the user environment, while the manufacturer-initiated requests were based on
manufacturer-specific knowledge.
Funhermore,
the
I
observed that roughly half (53%) of the requests from the user took
form of "Your software does not do what we asked" and often traveled betw,een the
manufacturer and the user (across the boundary) twice and occasionally traveled across the
boundary three times. Almost
all
of the requests for
from a software development firm person working
new
features
came from
directly at the client site.
the client or
24
Finally, the granularity of the requests
amount of work
significant
However,
I
(a chunk)
made
varies
~
there are requests for a
and requests for a specific change (an item).
found that the percentage of chunks and items requested for a project
independent of the firm's understanding of
its
business problem and
its
is
understanding of
custom software.
5 Trends in Software Technology
Von Hippel
(1990) argues that there
problem-solving in one
needed
software.
forth
I
Simultaneously, there
(Ward
1986).
locus,
predict that
If,
as
however, their jobs
application.
tool.
and innovation tend
loci of sticky data; the
is
sticky.
From
new
more
make
user.
I
because data
I
features in the
shifts
back and
in the user locus.
application software easier to develop
and problem-solving
Programmers
of developing an application will
In other words, the tool will
loci
this pilot study,
will
will
end up
his or her
become encapsulated
in the
automate the traditional interaction between the
suggest that this
is
a
more optimal way
in
one
continue to be busy;
be to create tools that enable the user to develop
The process
programmer and the
be
or
user locus and the manufacturer locus.
suggests, innovation
end up
will
will
among two
and that problem-solving thus
a technology trend to
von Hippel
it
to
it
the source of most of the requests for
is
also observed that data are sticky
between the two
I
an economy to be gained by concentrating
rather than distributing
site
for problem-solving
observed that the user
is
to partition tasks
between the user and the manufacturer than has previously been demonstrated.
25
5.1
An Example
An
of User
example of
Empowerment
this type
within E.I. du Pont de
of task partitioning
Nemours
&
Company,
Inc.
is
the development of expert systems
The AI Technology group has taken a
decentralized approach to expert systems development. TTie
the manufacturer, standardizing the tools and dispersing
Al group played
them
to the user
entire organization). Users developed applications with the tools.
These
the role of
community
tools
(the
were
continually evolving; however, users were shielded from the tool development by the
manufacturer (the AI group), which monitored the tool evolution and provided users with
the "latest and greatest" only
The manufacturer
(the
when
the "latest
and greatest" worked (Computerworld
Ai group) conirolled tht developed of tht
tools but not the
development of the applications. Therefore, the value of the application
not limited by the manufacturer's knowledge about
t^^e
user's
1987).
to the user
was
problem since the user
developed the application.
In this example, the manufacturer concentrated on developing tools that allowed the
user to develop his
own
application.
The manufacturer
did not have to transfer any of his
database, which contained knowledge about developing the tools, to the user.
Correspondingly, the user did not have to transfer any of his database, which contained
knowledge about a wide variety of highly technical systems,
result has
5.2
been an extremely successful use of expert systems within
Custom Software
So
far
I
vs.
Du
I
The end
Pont.
General Software
have discussed custom application software ~ software that
specific user's problem.
to
to the manufacturer.
is
designed for a
believe that the observations from this study are also applicable
more general software such
as
word processors, communication software, accounting
26
systems, and spreadsheets.
programmers
in such a
with the extra
(or,
way
from the
I
hypothesize that pieces of these applications will be built by
that the user can
user's
combine the pieces however he or she wants,
frame of reference, unnecessary) pieces being
unobtrusive. Using the computer science metaphor of "object-oriented programming,"
word processors, communication software, accounting systems, and spreadsheets can be
thought of as objects identical to the modules
I
described in the beginning of this paper.
A
user will be able to string these modules together to solve his or her specific application
needs.
An
example of a general software system using generic objects that a user can
configure to meet his specific needs
a specific system using Microstep
is
Microstep.^^
as follows: "If a
is
An
example of the implementation of
programmer wants
to
add a payroll
function for the sales department, and he or she has already built such a routine for the
marketing department, rewriting
dragging
it
with a line.
to the
[It
it
for sales
is
as simple as pointing at a
marketing design, and connecting
it
to the rest of the
symbol for
payroll,
marketing design
was] done in less than two minutes, and that included pauses for
explanations" (Lewis 1988).
These generic objects
will
still
be developed by software engineers. Users
develop the object-oriented programming and the
CASE tools of the
develop the generic modules that one can consider to be part of the
future,
tool.
nor
will
not
will they
Instead, the role
of the manufacturer will be to evolve tools such as these to a higher degree of functionalit)'.
The user
will
then bring them into his or her environment and configure them to his or her
specific needs.
13.
Syscorp International.
27
53
Disintermediation:
If
A
Possible Consequence
users generate the majority of application programs, the commercial providers of
may
application programs
begin to disappear. This will resemble the disintermediation
that has occurred in other industries (e.g., the direct
the use of on-line
buy and
computer services such
as
placement of
airline reservations, or
CompuServe instead of retail brokerages
to
sell stocks).
This disintermediation has already occurred in discrete segments of the computer
X
^fiAvre market. For e;;iriple,
when
I
otns l-C-3
*"irst
appeared on the ma^'ket, comm-.<-dal
software providers rushed to develop "1-2-3 Templates."
respectable template market would
develop their
own custom
Currently, there
is
exist.
However,
it
appeared that a
as use/s discovered hovv easy
it
was
to
templates, the template market disappeared.
a large
demand
for decentralized application software.
firms exist to provide custom software solutions to
to
Initially,
all sizes
Numerous
of users from small businesses
Fortune 500 companies. Most of these companies approach application development
a very labor-intensive manner.
Many
user information and transfer
across the boundary to the technical experts in the
it
in
functional experts are hired to specify and interpret
manufacturer organization, who then develop the software.
I
would predict
that the core business of these software
companies
will eventually
be
jeopardized. Instead of needing a massive functional organization to interpret user needs
and design applications systems around these user needs, these software companies
need
to
the user
will
be able to transfer their process technology to the user environment and then teach
how
to use the tools to
develop application software. The manufacturer firms
will
28
not add value in the development of application software for a specific user need. Instead,
they will add value by developing and transferring tools into the user environment at the
appropriate places.
The need
tools
even
if
for specialist
programmers
will
not be restricted to just the development of
disintermediation occurs. For example, large organizations will continue to
require the services of
programmers
to maintain formal structures for standardizing
information systems across functional and organizational boundaries.
Consider Frito-Lay,
the 1970's
and early
Inc.,
a leading manufacturer and distributor of snack-foods. In
1980's, Frito-Lay
had a
traditional, centralized
Management
Information Systems (MIS) department. However, since 1985, Frito-Lay systematically
decentralized the gathering of information (through the use of hand-held computers by the
route drivers) and the process of making decisions that occurs in the organization (through
the use of an Executive Information System on managers' desks).
warehouse," containing
the
MIS
all
of the transactional data for the organization,
department. However, the data are no longer analyzed by the
they once were. Instead, data are dispersed to the managers (in
as
once a day)
promotion
perform
A centralized "data
in
for the analysis.
maintained by
MIS
department, as
cases as frequently
order to be used for analysis, production planning, sales strategies, and
strategies.
specific,
many
is
The MIS department no longer
writes application software to
user-requested analysis on the data. Instead,
The
users responsible for
using the tools developed by the
it
develops the tools used
making the decisions perform the actual
MIS department.
analysis
Ultimately, this system will provide
information to the decision makers across organization boundaries on a timely basis. The
users will be able to tailor specific applications to their needs.
will
The manufacturer (MIS)
provide the necessary tools and standards for collecting and storing data (Applegate
29
1989).
In the
appropriate.
--
du Pont example, the AI group recentralized the applications when
They did not take
responsibilit)' for
the user that developed the application
was
group helped disperse generally useful tools
AI group helped develop
inaccessible to the
In both of
end
it
was
maintaining and evolving the application
still
responsible for
it.
However, the AI
to other parts of the organization. Also, the
the links to other, older systems that
would otherwise be
users.
t'.es'^ c-""es. tl'e'"
manufacturer. However,
this
multiple user bouiiuanes.
I
i^
a
vf^'^d
programming
^or '.ome
is
progr?mrning
o be done by the
driven by the need for consistency across
believe that in these ca^es, tasks vyouid be most effec'iively
partitioned by users developing their applications around a data
framework designed and
maintained by the manufacturer.
6 Conclusion
The
over the
role of the user in the software
last
few decades. In
basis for research
paper,
I
undertook a
pilot study to establish
an empirical
on the actual partitioning of application programming tasks between user
and manufacturer. While the
to partition tasks
this
development process has changed dramatically
results of the present study
between the end user and
do not pinpoint the optimal way
programmer of application
specialist
software,
they do demonstrate that both the user and manufacturer have rich databases of
information which are not easily transferred across the user-manufacturer boundary.
Therefore,
it is
important to consider task partitioning and the implications of sticky data
for the locus of irmovation
and problem-solving
in the
software industry. Finally, they
suggest the value of the manufacturer developing tools based on expertise in the
30
manufacturer's environment and then transferring these tools to the user's environment so
the user can develop his or her application independently of the manufacturer.
the issues explored in this paper create a substantial basis for a
more
I
rigorous empirical
study of different approaches to task partitioning and the impact of sticky data in
application software projects.
believe
31
References
Applegate. Linda. 1989. "Frito-Lay, Inc.. A Strategic Transition (C)." Harvard Business
SchoofCase Study #9-190-071, Harvard Business School, Boston, Mass., December 1989.
"Artificial Intellieence Spotlight: Interview with
(November
Ed Mahler - Dupont." Computenvorld,
1987"): 59.
Henderson, John, and Soonchul Lee. 1989. "I/S Design Team Performance: A Control
Theory Perspective." Sloan School of Management, Massachusetts Institute of Technology,
Cambridge, Mass.
Lewis, Peter H. 1988. "The Executive Computer." Tlie
Fll.
Meng,
Brita. 1990.
"Object-Orienied Pr'^gramn
in^."
New
York Times, 26 February 1988,
Macworld (January
1990): l/-'-80.
Orlikowski, Wanda J. 1989. "Division Among the Ranks: The Social Implications of
Tools for System Developers," 199-210. In Proceedings of the Tenth International
Conference on Information Systems, 4-6 December 1989, Boston.
CASE
Salawav, G. 1987. ".An Organizational Learning Approach to Information Systems
Development." MIS Quarterly 11, no. 2 (1987): 245-6-:.
von Hippel.
Eric. 1978.
Marketing A2, no.
1
"Successful Industrial Products
From Customer
Ideas." Journal of
(January 1978): 39-49.
von Hippel, Eric. 1990. "The Impact of 'Stick7 Data' on Innovation and Problem-Solving."
Working Paper No. 3147-90-BPS. Sloan School of Management, Massachusetts Institute of
Technology, Cambridge, Mass., April 1990.
von Hippel, Eric. 1989. "Shifting Product and Service Prototyping to Users: An Innovation
Process Advantage?" Working Paper No. 3032-89-BPS, Sloan School of Management,
Massachusetts Institute of Technology, Cambridge, Mass., June 1989.
von Hippel.
Eric. 1988.
The Sources of Innovation.
New
York: Oxford University Press.
von Hippel, Eric. 1989. "Task Partitioning: An Innovation Process Variable." Working
Paper No. 2030-88, Sloan School of Management, Massachusetts Institute of Technology,
Cambridge, Mass., April 1989.
Ward, Paul T. 1986. System Development Without Pain: A
Organizational Patterns. New York: Yourdon Press.
User's
Guide
to
Modeling
Wegner. Peter. 1989. "Learning the Language." Byte Magazine, 14 (March 1989): 245-50.
Date Due
,.
jUH.
o«v
Lib-26-67
'i'l'|i!ni|m|<|'|j|i|l|jj
3
iDflO
OObT=iO?0
1