I want to second Ruven's description of how new development and
maintenance work in companies that develop commercial software. One
might expect my company (Sun Microsystems) to be pretty different
than Rockwell, but everything Ruven says applies to us. The notion of
a "mainentance programmer" is very foreign to us -- once in a while
there will be a product that is being end-of-lifed, and there needs to
be someone working on bug fixes, even though no new development will
happen on the product (which means only really serious bugs get fixed
-- ones reported by customers who have a gold level service contract
or who play golf with our CEO :-); in those cases we will think of the
person working on that product as a maintenance programmer, but that's
only because their work is so limited -- they probably never write
more than 2 consecutive lines of code.
The additional skill required for completely new product development
is an architect -- someone to lay out what all the pieces are (that
there is an I/O configuration module), and how they fit together and
communicate with one another. But even the architects I work with do
some of what IT shops would call maintenance programming.
Robin Jeffries
|From: "Brooks, Ruven" <[EMAIL PROTECTED]>
|Subject: PPIG discuss: Worlds of Programming
|To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
|
|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
