transputers again was: The dissolution of Commodore 2930

On Fri, 17 Mar 06 12:51:51 GMT in alt.folklore.computers,

^^^ ?

The issue at stake tends to be whether you want to keep the old code exactly as is, or whether you want to make changes that you can have a reasonable certainty will work and can be tested at a reasonable cost. It's their call whether to: eliminate the changes, find someone else to do the work, pay for greatly increased debugging and testing, or pay for increased coding and testing. Complex maintenance effort seem to take about five times what it would take to do the work as original development, because you have to ensure your changes have no side effects, and current testing approaches are a lot more thorough than whenever the code originated.

I've never understood the non-programmer fascination with never eliminating old cruft: that's why whole software systems end up being replaced, because they are written as or become unmaintainable; whereas if programmers reduce entropy whenever they have to do maintenance, software lifespans could be greatly increased. It's amazing how much you can eliminate when the effects of a bit of cruft removal have cascaded through a body of code. From 30-50% is not unusual, as Charlie has also reported. Unused results combine into unused chunks of code, which generate unused variables and routines, which sucks even more useless code into oblivion. Where conditions were unfavourable towards direct elimination, I've migrated useless code to dead spots in the source (after unconditional returns, or whole routines to the end), then "commented" them out, then deleted them, in separate revisions.

Database software adds more structure to data, but also usually is a consequence of, or results in, more volume of data being handled, and therefore a bigger variety of possible conditions and exceptions to handle sensibly.

-- Thanks. Take care, Brian Inglis Calgary, Alberta, Canada

fake address use address above to reply