[mooreds]

> The vast majority of software is not written with that amount of churn.

My current employer has code that is 6 years old. I had coffee with a former colleague and they are still running code from when I was there, and I left 5 years ago.

Code lives longer than you think.

[cgrealy]

6 years is still young for code. My current employer has code that's 13 years old. My last had code that was nearing 20.

And there's nothing wrong with that. Old code isn't "bad". In fact, it's almost certainly better than new code, because it's been battle hardened. It's got that fix in it for that weird edge case.

[scarface74]

The last company I worked for was just trying to move off of a PowerBuilder+Sql Server 2008 system that was written by contractors in 1999 and maintained by two developers who had been there for 20 and 14 years.

What was wrong with it:

- neither the version of PowerBuilder or Sql server was supported by their respective companies.

- they were dependent on the two developers not getting hit by the lottery bus. Good luck trying to hire someone who knew PowerBuilder and/or was willing to learn it.

- the only way to access the program by the remote offices were Citrix Terminals.

I was originally brought in to lead the effort to modernize the system [1] but they had a change of plans when I got there and I ended up leading a completely separate effort.

[1] the plan I proposed was to upgrade to a newer version of PowerBuilder that could expose the system as COM objects, write a C# WebAPI around it. Write automated integration tests calling the Web service and slowly migrating the PowerBuilder code to C# and calling the underlying stored procs directly from C#.

[cgrealy]

I'm not saying that old code cannot be bad, merely that it's not bad because it's old.

Your approach seems like the right one.

[sanderjd]

Some code lives longer than you think it will, and some dies really quickly. The problem is that you never know which is which.