In the latest PPIG newsletter, Carl Hardeman asks why do developers fail to recognize that a software structure has become too complex
and needs fundamental re-engineering?
Unfortunately, I don't think the answer is that the developers fail to recognize the problem; it's their managers who
are refusing to allow them to do the re-engineering and the managers are behaving in a perfectly rational manner!! (which is the
reason I began the sentence with "unfortunately.")
The reason is that it very rarely pays to re-write an existing system that works even though its maintenance and testing costs are high
because of poor design. Consider the following example:
Suppose there is a product that over time has grown so complex that a team of 40 is required to maintain it;
in part, because of the complexity, adding new features requires huge effort. Suppose further that the developers
are convinced that, with a re-design/re-write, the team size could be dropped to 10, mostly by getting rid of testers. (Actually, if I were one of those
developers, I'd keep my mouth shut about this, because I might be one of the 30 who got laid off.)
The developers estimate that the re-write could be done with a team of 20 in two years.
The manager figures as follows: I want to put the best of the existing people on this together with some new people with new ideas
but I've got to keep the old product going. I'll bring in 20 new people over a year, half on the old product and half on the new one.
Figure a cost of 10 people for a year. Then, for two years, I've got to pay for 60 people not 40. At the end of the two years,
I'll have burned 50 additional people years above what it would cost me to maintain the existing product. Then, I begin to
save the cost of 30 people a year, so that towards the end of the second year, I'll have recovered my costs and begun
to reap the savings. Let's see, I don't get any benefit from the re-write until 4 2/3 years after I started?
All of this is presuming that the re-written product will be a quarter as costly to maintain. Why won't it become more
complex to maintain over time as well?
Faced with this high risk, the rational thing for the manager to do is conitnue with the current product and find ways of lowering
his programmer cost, say, by moving the work to a lower cost country.
I've intentionally shaded this scenario to favor the re-write. I think getting a staff reduction as high as 4:1 will be extremely rare,
and many organizations will choose to go for a lower defect rate than for dropping testers. I've also presumed that the estimate for the re-write
is spot on accurate and that the full development staff will be useable for the entire life of the re-write. Neither of these assumptions is very realistic.
A more acceptable solution would seem to be to incrementally transform the existing product into the new design. The acceptablility is only in the eyes of the decision makers
since the total actual effort is likely to be substantially higher than in the total re-write approach. The reason is that for the incremental re-writes, interfaces will
have to be developed between the old and new parts of the system. As the re-write proceeds, these interfaces will be thrown away and new ones built.
With successful products in well managed organizations, the road to success is likely to consist of selective, modest, redesign and re-engineering of the modules
which are modified most often and have the highest defect rates. Global, ground up re-design is likely to occur only in new product development or in poorly
managed organizations. (Perhaps we can persuade the Gates foundation to start the equivalent of the TIAA/CREF system for academics, so that programmers
who specialize in global re-design can have portable pensions and benefits, since they will have to change jobs a lot.)
Ruven Brooks
