The distinction between developers and maintainance programmers is
peculiar to large corporate IT shops, and is not a general distinction
in the software development world.
The organization I work for develops software products for sale
to customers. A product is delivered as a sucession of releases -
1.0, 1.x, ...n.n. Each release contains some mix of bug fixes, basic
architectural changes, and new features visible to end customers. Team
members generally are assigned to some particular area of functionality
in the product - for example, one programmer might get assigned to work
on the I/O configuration module. People working on a given part of the
product tend to do all of the work - bug fixes, re-writing, enhancements
on that section of the product.
My impression is that adding a lot of new functionality to an area of
a product results in a lot of new bugs. The consequence is that the
person who did the most new code in release n usual spends a lot of time
on maintenance in release n+1.
Of course, writing the code for a product release is probably less than a
third of the effort. Two thirds of the effort go into things like testing
the new release, upgrading the documentation, help sytem, tutorials,
developing and testing install procedures, etc. Probably, two thirds
of the product team is devoted to these activities. Writing a set of
test scripts to test the new features in the new release may not sound
like the world's most exciting software development effort, but it is
critical to getting the new release out the door.
The preceeding discussion applies to new releases of existing products.
It probably accounts for 98% of the effort in software product
development. Development of completely new product is a much rarer
event - even companies as big as IBM and Microsoft only come out with
2 or 3 completely new products in a year.
Ruven Brooks
Rockwell Software
