-- Leo's gemini proxy

-- Connecting to ew.srht.site:1965...

-- Connected

-- Sending request

-- Meta line: 20 text/gemini

2021-09-15

Re: Changing old code is risky

tags: software nosimpleanswer


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:

The person, who wrote most of it, is not available any more.

Their peer is still around, but the code is like 12 years old.

It may well be, that the toolchain to build it, is in dire need of love.

No unit tests, of course.

The state of the specs is unknown to me, they might actually be ok.


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


Home

-- Response ended

-- Page fetched on Wed Oct 20 19:12:02 2021