roberto writes:
But old code has a history. It survived bugs, fixed them, worked around them. It's also harder to understand. When you revisit old code it's harder to understand the context, the subtleties, the reasoning — even with good comments left behind. Dismissing the old code is both disrespectful and unwise.
gemini://taoetc.org/changing_old_code_is_risky/index.gmi
Yes, but: Not changing old code is possibly even more risky.
At dayjob we had just such a discussion a few days ago.
There is this piece of software, which runs on one of the several computing components, which comprise a complete machine. One might argue, that this piece is not the central part of the data/work flow. Maybe. But if you take it away, the whole thing fails to work. It is essential.
Now for the ugly details:
If the interface of said component were perfect, there would be no need to touch it. But the rest of the system has moved on.
I sincerely believe that not touching this code will only increase the problems in the future, once you must touch it for some reason. If it's not /living/ code, noone will understand its boundary conditions, the baked in assumptions, and all the fine grained details. But nothing of this is going away, not even if you rewrite the hole thing from scratch. Rewriting from scratch will retrace all the dead ends and errors, that were done long ago, when writing the thing, plus a few new ones.
So in this case I would argue: allocate the time (min. 2 people, min. 3 weeks) sit down and dissect the thing. Write unit tests along the way. Study the spec. And most importantly: do integration tests. Rest assured that conditions at customers sites are always different from what we can imagine.
Now on to exciting times with old code!
Cheers,
~ew