The changing role of the user in the development of application software

m UPP^BlE!;

^060

ob^^oso

l

i

HlliPiiil

ifii

i

DLv^ar

WORKING

PAPER

ALFRED

P.

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

Abstract

In seeking to betterunderstand thesources ofinnovation, researchers have

investigated the division of labor between user and manufacturer in the development of

new

products. Specifically, the "partitioningof tasks"

between

userand manufacturer has

drawn

attention.

In this paper. I explore the changing role of the userin the development of

application software. I argue that responsibility forapplication

development

is shifting

fromgeneric manufacturers ofsoftware to the users of the software. I hypothesize that,

given this shift, an efficient division oflabor entails manufacturers

who

develop "tools"

and

transfer

them

to the users.

The

userthen develops hisor her

own

applications using the

tools developed by the manufacturer.

I carried out apilot study

on

the actual partitioning of tasks

between

the userof

application software and the specialist developer ofthe software (the manufacturer). In

this study. I investigated several software projects undertaken by a single custom software

firm for three clients seeking applicationsoftware to automate aspects oftheir businesses.

Finally, I discuss several trends in software technologythatcould arise

from

thisongoing

The

Changing

Role

of the

User

in the

Development

of

Application

Software

1

Introduction^

Although most software applications are currently developed byprogrammers,

innovations in software

programming

tools and user-friendly

methods

to link these tools

increasinglyprovide users

who

are not

programmers

with the ability todevelop their

own

applications

more

efficiently and cost effectively.

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.

A

decade

ago, the user

was

required to specify the

problem

to apiogrammer,

who

would

then

assume

the task of writing the

program

in a complex

programming

language such as

COBOL

or

BASIC.

Ifthe user needed any changes

made

after he began using the

program, he

would

have to interrupt his

work

and try to describe his needsto the

programmer,

who

would thentake the necessarysteps to incorporate the changes into the

program. Today, auser can

implement

her financial

model

directly in a spreadsheet

program. She controls the entire development cycle accordingto her specific needs and

can quickly and freely

make

any necessary changes to the

program

as she works.

The

current evolution ofsoftware development tools appears to be shifting the

responsibility for application development from a specialist developerofsoftware (the

programmer)

to the user of the software.

New

programming

environments fordeveloping

application software (such as fourth-generation and object-oriented languages) are

appearing that not only dramaticallydecrease the cost ofdeveloping application software

1.1wouldliketothankEncvon Hippel and DavidJilkfor theirstimulatingandinsightfulcontributions to theworkcontainedinthis

and increase the value of the software to the user, but alsoenable the user to develop his or

her

own

applications.

The

impact ofthis trendwill, I believe, leadto a new,

more

effective

divisionof labor

between

the developer and the user ofsoftware.

In this paper, I explore the changing role oftheuser inthe

development

of

application software and seek to establish an empirical basis for research

on

the actual

partitioning ofapplication

programming

tasks

between

the user

and

the manufacturer

and

on the implications forimproved practice. I first

summarize

some

literature that exists

concerning this subject (section 2). I then turn to a brief history ofthe rolesofthe end user

and

specialist

programmer

-- _often

_employed

_{by a software "manufacturing" firm} -- _{in the}

overall

development

ofapplication software (section 3). Next, I discuss a pilot study that I

conducted to explore the different ways inwhich software

development

tasks are

partitioned

between

users

and

programmers

ofsoftware

and

the efficiencywithwhich

information that affectsapplication

development

is transferred

between

user

and

programmer

(section 4). In this study, I investigated three "first-of-kind" projects that

were

developed for

new

clientsby a custom software

company.^

I

examined

various 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

incompletenessof messages transferred, and the content ofusers' requests

(new

features

vs.bugs). Finally, I discuss

some

trends I have observedthat will increasingly have an

impact on the role of the user in the

development

of application software (section 5).

2

The

Literature

Various researchers have

examined

the divisionoflabor

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).

He

found that problem-solving

interdependencies

among

tasks can be predicted

and

then

managed

by either adjusting the

boundaries between tasks or reducing the barrier to problem-solving interactions across

boundaries.

More

recently, he discussed the effects ofwhat he terms "sticky data" on the

locus ofproblem-solving and innovation (von Hippel 1990).

He

found that

much

of the

data nejuc t u-;problcr.i-' )!• i. _^ h?s "sticky" qualities that

mak"

then: difn.uit o; ior> '.o:tly

to

move

to other sites.

He

hypothesized that "ifdata

needed

bya problem-solver are sticky,

related problem-solving activitymust

move

to

and

among

loci ofsticky data

-

perhaps

repeatedly as problem-solving proceeds" (von Hippel 1990).

Von

Hippel proposes that "it

is an

economy,

other things being equal, to design problems so thatproblem-solving draws

on

only one locus ofsticky data..." (von Hippel 1990).

A

number

of other researchers have investigated

how

the software development process is organized and inwhat ways and

how

effectively it incorporates userand

manufacturer input. These studies have

been

concerned primarily with partitioning of

tasks in technical organizations. Salaway (1987) suggests that interactions

among members

of a

team

occur at the intersection ofuser

knowledge

and designer knowledge.

Henderson

and

Lee

(1989) found that during the development ofan information system, designers

(software developers) were expected to build the system, but

domain

representatives

(users)

were

expected to supply relevant business knowledge and user input to the

relationship

between

user and developer in the

development

ofinformation systems

and

observed ashift in the division of labor

between

functional developers

and

technical

developers in a custom software organization following the introductionof computer-aided

software engineering

(CASE)

tools. All ofthese examples indicate that there is a

substantial transferofinformation

between

software user

and

software developer during

the development ofapplication software.

3

Roles

of

the

Programmer

and

the

End

User

in

the

Development

of

Software

The

software industry is beingtransformed by anincreasing separation of

programming

tasks:

The

creation ofapplication-generating

programs

(a "tool") and the

development ofapplication software (an"application") are

no

longer a single task

controlled by the

programmer,

as they once were.

In the 1960's,

programmers

usinglanguages such as

Assembly

handled all software

tasks.

Even

when

the distinction

between

a "tool" and an "application" did exist, the skills a

programmer

needed

to build a tool were the

same

skills

needed

to manipulate the tool to

create an application.

Over

time,

programmers

realized that their

work

could be facihtated bythe design of

reusable, self-contained modules.

These

modules, ortools,

became

fundamental

components

of

newer programming

languages.

While

early

programming

languages such

as

Assembly

contained no tools, later

programming

languages such as

COBOL

included

some

built-in, although limited, tools for developing input screens and reports. Current

programming

languages (such as Focus, Dataflex, or Clarion^) contain

numerous

toolsbut

3.Focus, Dataflex.andClanonareproductsofInformationBuilders.DataAccess Corporation, andClarionSoftwareCompany,

have

added

simple "user-friendly"

methods

to link these modules. For example, a

programmer

using an "object-oriented"^

programming

language suchas Actor^ can create

a"window"

on

the

computer

screenthat behaves like a text editor.

A

decade ago, this

operation

would

have taken thousands oflines of

programming

code written by anexpert

programmer;

today, it takes one line of

programming

codewritten by auser.

At

the

same

time, advances in the

power

and speed of

computer

hardware have

permitted software programs to use largerself-contained

modules

A-ithout diminishing the

performance of the software.

As

computing

power becomes

less expensive, software

modules

have

become more

complex without having avisible effect on the performance of

li.e arplicaticn.

Togetherwith this trend toward increasedcomputing power, trends toward

self-contained .nodules and easy, user-friendly

methods

to link these

modules

have

automated

tasks that previously could only be performed by specialist

programmers

and

have enabled the user increasingly to

program

his or her

own

applications. Today, auser

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-?.' For

example, the financial spreadsheet forecasting cash flowsthat

was

discussed 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

workingfor Lotus

4.Foragood descnptionofobjcci-oneniedprogramming,sec thearticlesbycitherWegner(1989)orMeng(1990). 5.ActorISaproductof theWhitewaterGroup

6.Amacroisa"programwthinaprogram" comprisedof asenesofcommandsorkeystrokesspecifictoa sofrn-areprogram thattheuser

canassembletoactasan applicationtosolvea specificneed

Corporation, is the application generator while the macro, developed by the user, is the

application.

The

pilot study discussed

below

seeks to take a firststep toward understanding

the impact ofsuch shifts.

4

Pilot

Study

4.1

Approach

My

goal in this study

was

to understand

how

applicationsoftware

development

is

partitioned

between

the

end

user and the software developer

and

how

information is

transferred -- _{or not transferred} --

_between

_{these two during the course ofsoftware}

development. In order to see such transfers clearly, I have elected tostudy situations in

which

end

users and the specialist

programmers

attempting to develop software to serve

their needs

were

employed

by different firms. Specifically, I studied the sources of516

improvements

in the application software developed for three clients ("users") by a single

custom

software application

company

("software manufacturer").

The

custom

software firm I elected to studyhas

been

inbusiness forfive years

and

has developed over 30personal computer-based

custom

software apphcations for awide

variety ofbusinesses. In the process, the firm also created

numerous

software

development

process tools and gained asignificant

amount

of

know-how

based around apopular

fourth-generation language called Clarion. ^

Some

samplesystems the firm has developed

include software forgroup medical practices, medical laboratory billing,venture capital

portfolio

management,

legal billing, insurance claim processing, real estate investment

analysis, rental store point-of-sale, and international accounting.

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 similarto rapid prototyping," the custom software

company

quickly generates

an initial, partial solution tothe client's

problem

and develops a custom application. TTie

client starts to use this software

and

then

makes

specific requests for changes.

The

software firm respondsand through these interactions the initial solution is greatly

elaborated and improved over time through aseries of"revisions" to the software issued as

software updates to the client.

At

the start ofa client relationship, software revisions

may

be shipped to the client as often as every two weeks. After a year, the frequency

may

(.eciine Xc. perhaps one revision eve'^ two monihs.

To

ensure that the user and manufacturer databases were distinct

from

each other at

the start of the study, I decided tc focus

on

"first-of-kind" software

development

p-ojects

--projects in industries in which the custom software firm

was

working for the first time. In a

first-of-kind project, the software firm had no significant knowledge ofthe client's field of

business and the client had notpreviously

been

involved ina custom software project.

Each

of the two databases (user and manufacturer) was, at least at the start of the

development project, in a different organization

and

at a geographicallydistinct location.

The

choice to study first-of-kind projects

was

based on the observation that, over time, the

software development firm inevitably learns something about the fields ofbusiness ofits

clients, resulting in a transferof

some

of the user's database to the manufacturer. Also, the

9.Rapidproiotypingisa softw.-arcdevelopmentmethodologymwhichtheprogrammerinlemcw-stheuser,getssomeinformationabout

theapplicationtobe developed,andcreatesa prolotj-pe. ITicuser then plays »nth the protot\peandgives themanufacturerfeedback,

whichcausesthe manufacturertodevelopanother, niore refinedprotot\-pe. ITiiscyclecontinuesuntiltheuser has asystemthat satisfies hisrequirements

8

client learns something about the custom sofr^-are

development

process, resulting in a

transferof

some

ofthe manufacturer's database to the user. I specifically looked for

projects

where

this exchange of knowledge

had

notyet occurred.

The

software

company

I studied was working

on

ten first-of-kindprojects. I then

categorized these ten

on

the basis of: (1) 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" forboth ofthese

characteristics.

I determined

how

the projects were classifiedwith respect to these two characteristics

byinterviewing the principals or project leaders ofeach of the tenfirst-of-kind clients

and

asking

them

questions about the business

problem

they

wanted

to automate. Ifthe client

described his business

problem

as "confusing (to him)" or said something like "I never had

to

work

inthe business office before, but I have to learn aboutit in orderto fix this

problem

in

my

business," I classified his understanding ofthe business

problem

as low.

Conversely, ifthe client clearly described the business

problem

he

wanted

to automate, or

ifpeoplewithin the client organization stated things such as "the boss really understands

how

this organization runs," I classified hisunderstanding ofthe business

problem

as high.

Ifthe client could onlyarticulate his

need

for software to "cut

down

on

the work" or

to "reduce personnel,"I classified the firm as having a low understandingof

custom

software. Ifthe client

was

already using software to analyze a

component

ofhisbusiness

problem, or if the client displayed

some

understanding of the software and the

computer

After differentiating the ten first-of-kind projects

on

the basis ofthese vao

characteristics, I selected three to study over a two-yearperiod: aventure capital firm

(portfolio

management),

an insurance claims processing firm, and agroup medical

10

Each

request for achange

was

an individual item recorded bya

member

ofthe

software

company

(usually a

programmer

or the projectmanager). I identified atotal of

516 requests affecting the threeprojects.

Each

revision consisted ofa setofspecific changes to the existingfunctions ofthe

application software

and

resulted from interactions

between

the user

and

the manufacturer

(see Figure 1 for anexample from the study). I had access to the 68 revisions issued bythe

firm. Table 2 shows the

number

of requests and the

number

ofrevisions foreach ofthe

three projects.

PORTFOLIO MANAGER

VERSION 1.65

01/12/89

New Features

1) Income from securities. A new trade type, "INCOME" has been added to represent income from interest

and dividends. Transactions for these trades must have a 'delta' of 0, and the amount of income from

securities and total proceeds colunns.

2) The extra company information has a new field, 'Lead VC. The portfolio summary report can be

filtered to include companies from one Lead VC only, or it can be printed as normal.

Enhancements

1) The Cost Analysis report now has Total Value and Difference coluins, in addition to the Total Cost

column.

2) The Trade Log reports (Investment, 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 comitments 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 network bugs were found and corrected.

Figure 1:

Sample

ofa Revision forthe Venture Capital Project

I then sought to examine various qualities ofthe information transferred

between

the

11

12

At

the beginningofeach project, two rich, distinct databases existed: the client's

understanding ofhis business

problem

and the software company's understanding ofthe

custom software

development

process. Recall thatall three projects

were

first-of-kind.

The

software

company

had

no

specific knowledge about the applicationthey

were

about to

develop before the project

began

and the client had not previously

been

involved in a

custom software project.

Each

ofthe two databases (user

and

manufacturer)

was

initially

in a separate organization and at a geographically distinct location.

Following are

my

findings for the three projects I studiedwith regard to the initiator

of the request (user or manufacturer), the granularity (chunksvs. items) of the messages

transferred across the organizational boundaries, the completeness or incompleteness of

the messages transferred, and the content ofuser requests

(new

featuresvs. bugs).

4.2.1 Initiator of

Request

Remember

that

my

goal in this study

was

to understand

how

software development is

partitioned

between

end

user

and

software developer

and

how

information is transferred

-or not transferred

- when

two very different, rich databases are each held indifferent

organizations. Consequently, it

was

important to determine whether the user orthe

manufacturer

was

initiatingthe requests for changes.

I used thewritten records ofthe firm to determine the initiator ofeach request.

When

the initiator ofthe request

was

unclear, I interviewed the

programmer

who

recorded

the requestto determine the source ofthe request.

The

breakdown

ofuser-initiated

13

14

4.2.2

Granularity

ofthe

Messages

Transferred

I identified two levels of granularity -- a "chunk" and an "item" -- that can be

distinguished

on

the basis of the

amount

of

work

involved for the software

development

firm in implementing the request. I define a "chunk" as a request fora

new

feature that

usuallyrepresents a significant

amount

ofsoftware development. I define an "item" asa

specific request that usually represents a change to an already

implemented

chunk.

For example, a request that

would

be classified as a

chunk

is:

"Implement

the

investment report." This is arequest thatrequires the

programmer

to perform a

number

of

different tasks inorder to

implement

the request. In this specific case, the prograrmner

would

have to write

program

code to perform several tasks: (1) format the investment

report, (2) search through the investment database and perform the calculations necessary

lOgenerate the appropriate output,

and

(3) generate the appropriate output. In a language

such as Clarion, this

would

require as

many

as

one hundred

linesof code that could take

up

to a day to write, test, and debug.

A

request that

would

be classified as an item is:

"Make

the total

column

on

the

investment report two characterswider." In this case, the

programmer

only has to perform

one task in order to

implement

the request -- _{that of}widening afield on the report. In

Clarion, this

would

require a change to one line ofthe

program

and

would

take fifteen

minutes to write, test,

and

debug.

Table 4 shows the

breakdown

ofchunks

and

items I observed in the sample.

Interestingly, the vast majorityof requests are for specificitems. In all three projects, there

15

16

4.23

Completeness

of

the

Messages

Transferred

Ineach project, both user and manufacturerdatabases

had

to be

drawn upon

inorder

to first generate

and

then solve eachchange request.

Von

Hippel (1989, 1990) has

suggested that there is a significant advantage to be gained by efficientlypartitioning

development tasks and by concentratingproblem-solving in asingle locus. Consequently,

inthis study I investigated whether(1) the rich data ofeach side, the software firm and the

client

who

were

in different loci, were in anysubstantial

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 for specificactions

-

stripped ofany rich database

content

- moved

between

the two loci duringthe software

development

work, or (3)

something "in-between" took place, e.g., the rich data

were

transferred

from

manufacturer

to userin certain cases.

Evidence forthe first pattern, the transfer ofrich data

between

loci,

would

be

interactions

between

the client and software firm inwhich (a) the client said, "Let us tell

you all about our business so thatyou can develop a software package for us," or (b) "Teach

us about

how

youwrite softwareso that

we

can figure out

what

we

need from

you," or (c)

"Let's get together and learn about each other so that

we

can do this projectjointly."

A

series of discrete client-software firm interactions

where

the data

remained

where

they

were

and only requests for specificactions

moved

between

the two loci

would

be

evidence for the second pattern.

On

the client side,

we

might expectto see extremely

specific requests

-

in effect,

"Do

this"

-

devoid of user data regarding the context ofthe

request or related reasoning.

On

the software firmside,

we

might expect to see very

specific responses

-

in effect.

"We

did this"

-

also devoid ofinformation regarding the

17

Evidence for the third pattern,

where

something "in-between" took place, would be a

combination of collaborative

work between

the userand manufacturer

and

specific

requests from eitherthe useror manufacturer. For example, the user

and

manufacturer

might begin the project with aseries ofmeetings to define the project. Then, the user

would

issue specific requests to the manufacturer during the life of the project. Finally,

periodic"workingsessions"

would

be held by the userand manufacturer to check the

progress of the project and to reestablish priorities.

Interestingly, inall three projects I found that virtuallyall of the data passing back

and forth between userand manufacturer

were

for specific requests -- _{essentially of a}

_"Do

th/'f" nature -- _{thereby providingsupport for the second pattern noted above.}

I observed

that the requests fell into two categories: (1) the initial

"Do

this" request

was

complete and

unambiguous enough

to al'ow the software firm to

implement

the request without further

information; or (2) the

"Do

this" request needed further amplification before it could be

implemented.

Typical

unambiguous

requests from the client (in this case, the venture capital

company) would

be: "The trade logdoes not always clear rightmost

column

-- it should" or,

"Where

you

now

print 'share' in the output reports,print 'shares' instead."

The

software

company

would

make

the requested change and issue another release ofthe software,

effectively saying, "The software

now

does

what

you asked us for."

An

example of a

"Do

this" request requiring further amplificationin the venture

capital project was, "Use percentage ofcost

method

for revaluation." In the case where the

"Do

this" request required further amplification, the software

company

was

only concerned

with collecting the information

needed

to do

what

the client had requested -- _{not with}

18

the software

company

did not investigate cost valuation equations inorder to see ifthere

was

abetter solutionto this particularrequest. Instead the

programmer

asked questions

like,

"How

would

you calculate the percentage ofcostfor a revaluation?" in order to

understand

how

to

implement

the request.

I also found that a request for further amplification is

much

more

likely for chunks

than for items, as in Table 6.

19

Hypothetically, it is possible for the manufacturer to learn the user's business and mix

the two databases. But, according to the interviews I conducted, this is not

what

happens.

The

manufacturerobtains

more

information so that he cansatisfy the

"Do

this" requests,

but he does not necessarily understand the user's database.

In the case of the venture capital client, the usersinvolved understood PC-based

software

and were

often able to simulate

what

they

wanted

in terms of functions before

making

a

"Do

this" request of the software development firm.

When

the user is already

familiarwith

some

programming

tools, she does a betterjob offraming the

problem

for the

manufacturer. At the venture capital company, the user understood

programming

well

enough

to be able to prototype the

problem

in Lotus 1-2-3. Consequently, the user

partitioned the

problem

and transmitted

"Do

this" requests that

were

clear

and

actionable

bythe remotely located manufacturer.

At

the venture capital company, the users also understood their business well. In this

case, their knowledge of the capability of the software firm

was

sufficient to alloweffective

interaction by both the user and the manufacturer at arm's length. Consequently, neither

firm had to transfer anyrich data to the other side to havean effective interaction

regarding changes to the software.

In the case of the insurance claims processing company, the client understood his

business reasonablywell, but did not understand the software development process.

The

client also had a

good manual

system in place that

needed

to be automated. Consequently,

the software firm studied the

manual

system in order to derive the series of

"Do

this"

statements it

needed

to proceed. In this case,

some

rich data

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 eitherspecific requests or an understandingof its

database to the remotely located software

development

firm. In addition, the client's

understanding ofits business

problem

was

low. Specifically, the existing

manual

proceduresthe firm

wanted

to automate were poorlyunderstood 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 there,

however, he did not collect arich understanding ofthe user database

and

transfer it to the

manufacturer. Instead, he concentrated

on

"understanding

what

we

(the manufacturer)

were

supposed to do."

Finally, note that in

none

ofthe cases

were

software

development

tools transferred to

the user site so that the user could modifythe software provided by the manufacturer. In

fact, it

was

the policy ofthe software

company

not to transfer such tools to the user so as to

retain a proprietaryadvantage over other developers ofcustom software.

4.2.4

Content

of

User

Requests:

New

Features

vs.

Bugs

I observed that 455 of the 516 requests

were

transmitted

from

the user site to the

manufacturer site.

Von

Hippel (1989) has suggested that the traditional partitioning of

tasks

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 interdependencyof

problem-solving. Consequently, in this study, I exploredwhether

problems

crossed back

21

Because the rich user and manufacturer databases had been kept separate bythe

design ofthis study, the different typesofrequests by the usercould in large part be further

examined

and categorized. I divided these requests into three categories: (1)

new

features,

(2) bugs, and (3) specification errors.

New

features

were

requests by theuser for changes to the software

program

that

resulted in the

program

performing

new

functions.

These

new

features were typically

either logical extensions ofprevious

work

that had

been

done

or distinct

new

"modules"

that automated processes that had not been previously automated.

An

example

of a

new

feature request

from

the venture capital project is

"Summarize

quarterly totals

on

the trade

logs."

New

features coulo cither bi^ a "chunk"or an"item." Ifa

new

feature required

more

than one

programming

task to implement, it

was

considered a chunk. If it required only

one programm'ng

task, it

was

considered an item.

Bugs were functions that the manufacturer had

implemented

thatdid not

work

correctly.

These

are different from requests that

were

poorly defined by the user, classified

below as "specification errors." In the case ofbugs, the

program

simply did notwork.

An

example

of a bug

from

the venture capital project is "Transactions out of order cause the

liquidationschedule to print the

wrong

information."

Specification errorswere requestsby the user that

were

poorly defined. In these

cases, the user

made

a request that,

when

implemented

bythe manufacturer,

prompted

the

user to revise the original request. While these requests were not actually bugs, theyare

clearly distinct from

new

features.

The

classificationof user requests into

new

features, bugs, andspecification errors

?'»

23

who

were

new

to the topic area in each case, could not suggest auseful

new

function to the

users

on

the basis of problem-solving carried out atthe manufacturersite. This is

consistent with the observation that most of the

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 ofthe information transfer that

tookplace

between

the end userand the software developer in three first-of-kindsoftware

application developmentprojects. I found that in all three projects most ofthe data

passing back and forth beivveen user an \ manufacture/were for specific re'uests of a

"Do

this" nature. I obser\'ed thatthese requests fell into two categories: (1) the initial

"Do

this"

request

was

complete and

unambiguous enough

to allowthe software firm to

imp'ement

the request without further information; or (2) the 'Do this" request

was

incomplete and

needed

further amplificationbefore it could be implemented. In addition, the request for

further amplification

was

always initiated bythe manufacturer.

Ialsofound that most requestsfor changes

came

from the user

(88%)

rather than the

manufacturer (12%).

The

user requestswere all based

on

specific informationcontained

withinthe userenvironment, while the manufacturer-initiated requests

were

based

on

manufacturer-specificknowledge.

Funhermore,

I observed that roughly half

(53%)

of the requests

from

the user took

the form of"Yoursoftware 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

new

features

came

from

the client or

24

Finally, the granularityofthe requests

made

varies

~

there are requests fora

significant

amount

of

work

(a chunk) and requests fora specific change (an item).

However,

I found that the percentage ofchunks

and

items requestedfor a project is

independent of the firm's understanding ofits business

problem and

its understanding of

custom software.

5

Trends

in

Software

Technology

Von

Hippel (1990) argues that there is an

economy

to be gained by concentrating

problem-solving in

one

site rather than distributing it

among

two or

more

loci because data

needed

forproblem-solving and innovation tend to be sticky.

From

thispilot study, I

observed that the user isthe source ofmost ofthe requests for

new

features in the

software. I also observed that data are sticky

and

thatproblem-solving thus shifts back

and

forth

between

the two loci ofstickydata; the user locus

and

the manufacturerlocus.

Simultaneously, there is a technology trend to

make

application software easier to develop

(Ward

1986). If, as

von

Hippel suggests, innovation

and

problem-solvingwill

end up

inone

locus, I predict that it will end

up

in the user locus.

Programmers

will continue to bebusy;

however, theirjobs will be to create tools that enable theuser to develop his or her

application.

The

process ofdeveloping anapplicationwill

become

encapsulated in the

tool. In otherwords, the tool will automate the traditional interaction

between

the

programmer

and the user. I suggest that this is a

more

optimal

way

to partition tasks

25

5.1

An

Example

of

User

Empowerment

An

example ofthis type oftask partitioning is the developmentof expert systems

within E.I. du Pont de

Nemours

&

Company,

Inc.

The

AI

Technology grouphas taken a decentralized approach to expert systems development. TTie

Al

group played the role of

the manufacturer, standardizing the tools and dispersing

them

to the user

community

(the

entire organization). Users developed applications with the tools.

These

tools

were

continually evolving; however, users were shielded from the tool development bythe

manufacturer (the

AI

group), which monitored the tool evolution and provided userswith

the "latest and greatest" only

when

the "latest

and

greatest"

worked (Computerworld

1987).

The

manufacturer (the

Ai

group) conirolled tht developed of tht tools but not the

development of the applications. Therefore, thevalue of the application to the user

was

not limited by the manufacturer's knowledge about t^^e user's

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

manufacturerdid not haveto transfer anyof his

database, which contained knowledge about developingthe tools, to the user.

Correspondingly, theuser did not have to transfer anyof his database, which contained

knowledge

about awide variety of highly technical systems, to the manufacturer.

The

end

result has

been

an extremely successfuluse ofexpertsystems within

Du

Pont.

5.2

Custom

Software

vs.

General

Software

So farI have discussed custom application software

~

software that is designed for a

specific user's problem. I believe that the observations from thisstudy are also applicable

26

systems, and spreadsheets. I hypothesize that pieces ofthese applications will be built by

programmers

insuch a

way

that the user can

combine

the pieces

however

he or she wants,

with the extra (or, from the user's frame of reference, unnecessary) pieces being

unobtrusive. Usingthe

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 inthe beginningof this paper.

A

userwill be able to string these

modules

togetherto solve his or her specific application

needs.

An

example

of ageneral software system using genericobjects thata user can

configure to

meet

hisspecific needs is Microstep.^^

An

example

ofthe implementationof

aspecific system using Microstep is as follows: "Ifa

programmer

wants to

add

apayroll

functionfor the sales department, and he or she has alreadybuilt such a routine forthe

marketing department, rewriting it for sales is as simple as pointing at a symbol for payroll,

dragging it to the marketing design, and connecting it to the rest ofthe marketing design

with a line. [Itwas]

done

in less than two minutes,

and

that included pauses for

explanations" (Lewis 1988).

These

generic objectswill still be developed by software engineers. Users will not

develop the object-oriented

programming

and the

CASE

tools ofthe future, norwill they develop the generic

modules

that

one

can consider to be part ofthe tool. Instead, the role

of the manufacturerwill be to evolve tools such as these to a higher degree offunctionalit)'.

The

userwill then bring

them

into his or her environment and configure

them

to his orher

specific needs.

27

53

Disintermediation:

A

Possible

Consequence

Ifusers generate the majorityof application programs, the commercial providers of

application programs

may

begin to disappear. This will resemble the disintermediation

that has occurred in other industries (e.g., the direct placement ofairline reservations, or

the use ofon-line

computer

services such as

CompuServe

instead ofretail brokerages to

buy and sell stocks).

This disintermediation has already occurred in discrete segments of the

computer

X ^fiAvre market. Fore;;iriple,

when

I otns l-C-3 *"irstappeared

on

the ma^'ket, comm-.<-dal

software providers rushed to develop "1-2-3 _Templates." Initially, it appeared that a

respectable template market

would

exist.

However,

as use/s discovered hovveasy it

was

to

develop their

own

custom templates, the template market disappeared.

Currently, there is a large

demand

for decentralized application software.

Numerous

firms exist to provide custom software solutions to allsizes of users

from

small businesses

to Fortune 500 companies.

Most

of these companies approach application development in

a very labor-intensive manner.

Many

functional experts are hired to specify and interpret

userinformation

and

transfer it across the boundary to the technical experts in the

manufacturer organization,

who

then develop the software.

I

would

predict that the core business ofthese software companieswill eventuallybe

jeopardized. Instead ofneeding a massive functional organization to interpret user needs

and design applications systems around these user needs, these software companieswill

need to be able to transfer their process technology to the userenvironment and then teach

28

not add value in the

development

ofapplication software fora specificuser need. Instead,

theywill addvalue bydeveloping and transferring tools into the user environment at the

appropriate places.

The

need

for specialist

programmers

will not be restricted to just the

development

of

tools even ifdisintermediation occurs. For example, large organizations will continue to

require the services of

programmers

to maintainformal structures for standardizing

information systems across functional

and

organizational boundaries.

ConsiderFrito-Lay, Inc., a leading manufacturer

and

distributor of snack-foods. In

the 1970's

and

early 1980's, Frito-Lay

had

a traditional, centralized

Management

InformationSystems

(MIS)

department.

However,

since 1985, Frito-Lay systematically

decentralized the gathering of information (throughthe use ofhand-held computers by the

route drivers) and the process of

making

decisions thatoccurs in the organization (through

the use ofan Executive Information System on managers' desks).

A

centralized "data

warehouse," containing all of the transactional datafor the organization, is maintained by

the

MIS

department.

However,

the dataare

no

longer analyzed by the

MIS

department, as

theyonce were. Instead, data are dispersed to the

managers

(in

many

cases as frequently

as once a day) in order to be used for analysis, production planning,sales strategies,

and

promotionstrategies.

The

MIS

department no longerwrites application software to

perform specific,user-requested analysis

on

the data. Instead, it develops the toolsused

for the analysis.

The

users responsible for

making

the decisions perform the actual analysis

usingthe tools developed by the

MIS

department. Ultimately,this systemwill provide

information to the decision

makers

across organization boundaries

on

a timely basis.

The

userswill be able to tailor specificapplications to their needs.

The

manufacturer (MIS)

29

1989).

In the du Pont example, the

AI

group recentralized the applications

when

it

was

appropriate.

They

did not take responsibilit)' for maintainingand evolving the application

-- _{the user that developed the application}

_was

_{still responsible for it.}

_However,

_the

_AI

group helped disperse generally useful tools to other parts of the organization. Also, the

AI

group helped develop the links to other, oldersystems that

would

otherwise be

inaccessible to the end users.

In both oft'.es'^ c-""es. tl'e'" i^ a vf^'^d ^or '.ome progr?mrning

o

be

done

bythe

manufacturer.

However,

this

programming

is driven by the need for consistency across

multiple user bouiiuanes. I believe that in these ca^es, tasks vyouid be most effec'iively

partitioned byusers developing their applications around a data

framework

designed and

maintained bythe manufacturer.

6

Conclusion

The

role of the user in the software development process has changed dramatically

over the last few decades. In this paper, I undertook apilot studyto establish an empirical

basis for research on the actual partitioning of application

programming

tasks

between

user

and manufacturer. While the results ofthe present study

do

not pinpoint the optimal

way

to partition tasks between the end user and specialist

programmer

of application software,

they

do

demonstrate that both the user and manufacturer have rich databases of

information which are not easilytransferred across the user-manufacturer boundary.

Therefore, it is important to consider task partitioning and the implications ofstickydata

forthe locus ofirmovation and problem-solving in the software industry. Finally, they

30

manufacturer's environment and then transferring thesetools to the user's environment so

the user can develop his or her application independently ofthe manufacturer. I believe

the issues explored in this papercreate a substantial basis fora

more

rigorous empirical

study ofdifferent approaches to task partitioning

and

the impact ofsticky data in

31

References

Applegate. Linda. 1989. "Frito-Lay, Inc..

A

StrategicTransition (C)." Harvard Business

SchoofCase

Study #9-190-071, Harvard Business School, Boston, Mass.,

December

1989.

"Artificial Intellieence Spotlight: Interviewwith

Ed

Mahler

-

Dupont." Computenvorld,

(November

1987"): 59.

Henderson,John, and Soonchul Lee. 1989. "I/S Design

Team

Performance:

A

Control

Theory

Perspective." Sloan School of

Management,

Massachusetts Institute ofTechnology, Cambridge, Mass.

Lewis, Peter H. 1988. "The Executive Computer." Tlie

New

York Times, 26 February 1988,

Fll.

Meng,

Brita. 1990. "Object-Orienied Pr'^gramn in^."

Macworld

(January 1990): l/-'-80.

Orlikowski,

Wanda

J. 1989. "Division

Among

the Ranks:

The

Social Implications of

CASE

Tools for System Developers," 199-210. In Proceedings of the Tenth International

Conference on Information Systems, 4-6

December

1989, Boston.

Salawav, G. 1987. ".An Organizational Learning

Approach

to Information Systems Development."

MIS

Quarterly 11, no. 2 (1987): 245-6-:.

von Hippel. Eric. 1978. "Successful Industrial Products

From

Customer

Ideas." _{Journal of}

MarketingA2, no. 1 (January 1978): 39-49.

von

Hippel, Eric. 1990. "The Impact of 'Stick7Data'

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 ofTechnology, Cambridge, Mass., June 1989.

von Hippel. Eric. 1988. TheSources ofInnovation.

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 ofTechnology, Cambridge, Mass., April 1989.

Ward,

Paul T. 1986. System Development Without Pain:

A

User'sGuide to Modeling OrganizationalPatterns.

New

York:

Yourdon

Press.

Date

Due

,.

o«v

jUH.

'i'l'|i!ni|m|<|'|j|i|l|jj

3 iDflO

_OObT=iO?0