Pennington: Professional corner-cutting

Pennington: Professional corner-cutting

Posted May 8, 2016 6:51 UTC (Sun) by epa (subscriber, #39769)
In reply to: Pennington: Professional corner-cutting by dlang
Parent article: Pennington: Professional corner-cutting

If you are looking ahead a bit, you will see areas that you know you are going to replace in the near future.

I think this is often unwise. Firstly because such code has a habit of staying around longer than expected. A component can be 'deprecated' or 'obsolete' or 'on the way out' and stay that way for a decade if in production. In fact, getting rid of existing code is even more likely to slip behind schedule than other programming tasks.

The second reason is that letting something cruft up and become essentially unmaintained will make it more difficult to replace. The replacement code has to do the same job and may even have to produce the same result given the same input. If the old code is buggy you may have to carefully implement bug-compatibility in its replacement; better to first fix a bug in the existing code (as a small, narrowly scoped change) and then later switch out the implementation without changing the outwardly visible behaviour. If you try to do both at once in a production system that is more risky.

Finally, in maintaining the older component properly and cleaning it up where possible, you gain the necessary familiarity with the job it needs to do and any 'gotchas' which the code has evolved to work around. This is particularly true where the older version was written by somebody else. It is the easiest thing in the world to look at crufty old code you inherited, go 'blech' and set out to rewrite it from scratch... but this is usually a mistake. Fix it first, and when you have gone through that formative experience you will be a better and wiser programmer and you can decide whether to rewrite it.

For these reasons I think that 'areas you know you are going to replace' is a poor metric for deciding where to let technical debt pile up. Sadly, even old and obsolete code needs the same standard of maintenance, until it is finally turned off in production and deleted from the codebase.

---

to post comments