🚀 go-pugleaf

In article <3807@rtech.rtech.com> linda@rtech.UUCP (Linda Mundy) writes:
>In article <16187@vail.ICO.ISC.COM> rcd@ico.ISC.COM (Dick Dunn) writes:
>>I know of no way to specify software requirements such as "must be able to
>>survive the next five years of changes, to meet new needs, hacked in by
>                                                            ^^^^^^^^^^^^
>>bored second-string maintenance programmers..."  ...
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>     .....  I personally think that
>any new, just-out-of-school programmer should do maintenance work for awhile
>(assuming, of course, that the company already has a product!)  It will
>introduce them to the product they will be working on, in a context where they
>can both learn and have something to show for it.  ...

I agree with the policy of assigning rookie programmers to maintenance
tasks.  The learning experience is wonderful.  Most companies I've
worked for tend to follow this policy, and I believe that this is
what leads to Dick's view of maintenance programmers.

1) "hacked" -
	Being rookies, they are still learning the product, style,
	and problems of real-world (large complex systems) programming.
	Their code tends to lack the polish of craftsmanship.

2) "bored" -
	Being youthful, they still possess the dream of setting the 
	world on fire. "Enough of this working on last year's code,
	I want to design the next major system."  They are being forced
	to walk when they want to run. 

3) "second-string"
	Of course they're second-string.  They still have to prove
	themselves to management; and until they do, the more senior
	people of the team continue to carry the ball.

There is yet another reason for assigning junior programmers to
maintenance tasks.  Don't forget that maintence represents ~80% of
the life cycle costs of a software product.  By assigning programmers
from the low end of the pay scale, these costs may be reduced.

All of the above sounds brutal, but the benefits, to both the
programmers and the companies who pay their salaries, are very
significant.

 My pet peeve regarding quality software is programmers
who insist on the status quo, without considering improvements in
their toolkits and development processes.  These programmers are
still producing code with last year's methods and setting poor
examples for the junior programmers who have to fix that code next year.

Quality development is an continual spiral.  As you introduce
quality improvements, the quality of the each succeeding product
generation improves.  The inverse is also true.  If you do not
introduce quality improvements in the development process,
the quality of the future products continues to deteriorate.
The real problem for management is the intial cost of getting into
the right spiral.  Once on the proper path,
quality methods becomes second nature.

Steve Shapland
Interactive Systems Corp.