Ruven Brooks asked:

> Under what circumstances does a replacement model make sense?

I note that the organisations with which Ruven is familiar are all of
a type that I might call "technical software" organisations, rather
than "business software" organisations. (He lists Rockwell Software, 
Microsoft, IBM, Sun Microsystems - no banks, insurance companies,
healthcare providers, government agencies etc).

My experience of commercial software development is also in this 
type of organisation, where I have experienced much the same attitude
to product maintenance that Ruven describes. However I do have some vicarious 
experience of "business software" organisations from discussions with my 
wife, who has worked in three such organisations - all multinational
companies in three different business fields [banking/consultancy/software 
sales], and with their software development activity in three different 
geographical centres [USA/UK/NZ].

With the resulting proviso that these are second-hand observations, 
I would note the following points:

1. These organisations are divided into project teams, rather than 
separate departments for maintenance and development. Some teams 
work on "maintenance projects", where the product is already in service, 
and design decisions are hence constrained by existing user base and
application contexts. Other teams work on "development projects", where
the design constraints are far freer. Ambitious business programmers
prefer to work on development projects, where they feel that they can
leave their creative mark on the product design. Programmers are 
therefore generally recruited into development project teams, which 
gradually turn into maintenance teams as the product is implemented 
and gains a user base. If they are sufficiently ambitious, team members
either leave the company at this stage, or agitate to be moved into a
new development team.

2. These organisations *are* divided into different departments for
development and "production". The production department is responsible
for keeping the current release of the system running, and hence becomes
involved in maintenance tasks such as efficiency improvements, required
modification to support hardware upgrades and so on.

The dynamics of maintenance versus development activity is hence a 
complex social phenomenon, in which the career aspirations of individual
programmers interact with the inter-departmental politics surrounding the
tensions between the greatly differing priorities of development and
production. I'm sure that the political difficulties of the situation
is largely responsible for the trend that Anneliese mentioned - where
large organisations "outsource" their maintenance to subcontractors.

I'm sorry to introduce personal anecdotal material into a discussion
where other contributors are able to cite academic studies, but I'm 
interested that nobody else has described this kind of organisation,
which seems to me as though it must be very common.

Alan
-- 
Alan Blackwell           Computer Laboratory, University of Cambridge
http://www.cl.cam.ac.uk/users/afb21/       Phone: +44 (0) 1223 334418        

Reply via email to