Software Rot (2017)

if there aren't system/integration tests - write system tests. you have to be pretty thorough.

have a long and involved discussion about what the new thing is going to be. go through all the frustrations with the current code base. convince yourself at the end that its going to be worth it, because the cost is going to be high. ideally the new version will open up new capabilities that just weren't possible before.

find a cut in the dependency graph. you're going to rewrite the code on one side and leave the other side untouched. ideally that cut will be small-ish and contain some particularly broken stuff that you'd like to get rid of as soon as possible. unfortunately there may not be a small cut that makes sense :-(

build a shim between the old model and the new model across the cut. this shim is only going to last as long as the old code on the other side. this shim might be involved and a total waste of effort. suck it up or look for a different cut.

replace the code on the new side and test against your suite. if its not really that exhaustive, expect a rash of bug reports. run through some kind of soft deployment. if its a request/response kind of thing consider forking your production traffic and comparing the results against the old code base.

repeat until golden brown.

this overall process also can fail. often because of poor test coverage, and more likely because you haven't adequately communicated the scope of the undertaking and its absolute necessity to the rest of the engineering organization and the business as a whole.

however, if you make it through, you've avoided the giant speed bump that comes at the end of the rewrite, and you've been able to fold in new feature and bugfix work along the way.

Rot is when something breaks down while environment remains the same. What happens with software is the opposite: it forever remains in pristine condition; it's the environment that changes.

(Compare also with description of evolution. A species does not "rot". It dies off when its niche changes so much its no longer adapted to survive in it.)

It varies from shop to shop, but what I've seen is that code organization has a lot to do with it. Basically, if your code organization/factoring is really bad, then it's more likely that porting becomes untenable. Ironically, these are the projects that can have the longest lifespans, sometimes developing a history of multiple failed attempts to "port" them. (Really, re-implement while incurring huge opportunity costs.)

> If all of the environmental variables remain the same

Would you like a pony too?

You're seriously missing the point. My point is that the environmental variables never remain the same. (I was making two points, and I think you missed where I switched.)

> 2) you have a reliable syntax driven code rewrite tool

Would you like a pony too?

I repeat. I've been paid good money to use such a tool. I've used such a tool to enable the 1-step-removed porting of a project to a different language variant. Instead of doing the port myself, I was refining a tool which automated the port and enabled the maintainers to easily port all the changed code they were checking in. This lets you do a port without incurring the opportunity cost. I know of a consulting company that once made most of their income with this.

Yes, you can automate away the easy cases, but that's not even half the battle.

You can't simply hit a switch with this, of course. Someone has to put real thought into how the translations are made, especially if you want idiomatic, readable code going out the other end. The good thing about consistent idioms, is that they can be leveraged to multiply that work. The manual part can be re-leveraged through automation.

That's why people hire maintenance programmers like you.

That could be read in a way that sounds less than friendly and maybe a bit elitist.

C++ in particular has also changed a lot since the 90s including how permissive the compilers used to be, even for stuff covered by c++98.

    $ make
    cc -n -O   -c -o sed0.o sed0.c
    In file included from sed0.c:2:
    sed.h:116: warning: declaration does not declare anything
    sed.h:128: warning: declaration does not declare anything
    sed0.c: In function ‘main’:
    sed0.c:32: error: ‘union reptr’ has no member named ‘ad1’
    sed0.c:48: warning: incompatible implicit declaration of built-in function ‘exit’
    <snip many more lines>

We can fix the source to deal with this and produce a working binary. But then, what would we do with it? We can't really install it as /bin/sed. The world now expects /bin/sed to support switches and syntax that this sed does not. Trying to use this as /bin/sed would cause lots of programs to fail. The definition of what exactly constitutes a working "sed" program has also changed.

So it seems to me like sed already has rotted in some sense. Looking forward, the sed from a current system is likely to be similarly rotted when you try to use it on a machine 40 years from now.

Well...

The code might very well work the same, but the dependencies were a nightmare: They were scattered across 14 different CDs and web sites. One provider of often used components had gone out of business, luckily those components were released on sourceforge.

Since there wasn't pom.xml (forgive me for mentioning a Java-thing here, but this was long before package.json or ProjectName.csconf was invented) in Delphi projects one also had to go through a bit of research, trial and error to figure out which versions was needed and the exact ones that were compatible with each other.

Luckily we had a seasoned, well paid Delphi expert at hand and we got it working in just under 3 days.

If anything I'd say this is a great example of (one form of) bit rot.

Now that I think of it it might very well have been the same week that I left behind my last bit of prejudice against Java and started openly preferring it.