3 ms·

5 years ago was 2012. Do you have code written in 2012 still in production? Almost certainly. 10 years ago was 2007. So you have code written in 2007 still in

5 years ago was 2012. Do you have code written in 2012 still in production? Almost certainly. 10 years ago was 2007. So you have code written in 2007 still in production? Less likely, but I bet there are enough "yes" answers out there.

joshuamorton 9y ago
There's a difference between code written and tools you used. Just to compare, 2007 was the time of python 2.5, Java 6 and Windows Vista. I would certainly hope people have upgraded to newer tools than those.
- cryptarch 9y ago
  And 2017 is the time of Windows XP and WannaCry. What I'm saying is, those things are all still running in prod. I got an employer off Java 6 just two weeks ago. The next step is all the Java packages that were deprecated 5 years ago.
  - joshuamorton 9y ago
    Right, and Windows XP was deprecated 3 years ago after a 12 year lifespan. That people are still using XP is, honestly, inexcusable. If you want a 10 year deprecation policy for something someone else is maintaining, you should be prepared to pay for the salaries of the engineers who will maintain it for the 5 years after everyone else has moved off the system, or just build your own api ;)
dmd 9y ago
Most of my company's clients have code from 1997 still in production, and at least a third have code from 1987 still in production. A few have code from 1977 still in production. I'll give you one guess what sector :D
derefr 9y ago
But many of the companies whose APIs you might have started using in 2007 are long dead: bankrupt; acquihired; pivoted into completely different verticals... If you truly want API longevity at that scale, we probably need some force beyond that of quarterly-profit-driven companies to actually achieve it. Maybe some nonprofit (the Internet Archive, maybe) could offer "API insurance" packages, where—in exchange for your premiums—they'd build and maintain API-compatible replacements for any and all services the insurance-holders rely on, if said services should happen to die. Then you'd just need to insist (with force) that all network-RPC-based "client" libraries have configuration to let you easily change their endpoints and expected X.509 trust anchors...

joshuamorton 9y ago

There's a difference between code written and tools you used. Just to compare, 2007 was the time of python 2.5, Java 6 and Windows Vista. I would certainly hope people have upgraded to newer tools than those.

cryptarch 9y ago
And 2017 is the time of Windows XP and WannaCry. What I'm saying is, those things are all still running in prod. I got an employer off Java 6 just two weeks ago. The next step is all the Java packages that were deprecated 5 years ago.
- joshuamorton 9y ago
  Right, and Windows XP was deprecated 3 years ago after a 12 year lifespan. That people are still using XP is, honestly, inexcusable. If you want a 10 year deprecation policy for something someone else is maintaining, you should be prepared to pay for the salaries of the engineers who will maintain it for the 5 years after everyone else has moved off the system, or just build your own api ;)

dmd 9y ago

Most of my company's clients have code from 1997 still in production, and at least a third have code from 1987 still in production. A few have code from 1977 still in production. I'll give you one guess what sector :D

derefr 9y ago

But many of the companies whose APIs you might have started using in 2007 are long dead: bankrupt; acquihired; pivoted into completely different verticals... If you truly want API longevity at that scale, we probably need some force beyond that of quarterly-profit-driven companies to actually achieve it. Maybe some nonprofit (the Internet Archive, maybe) could offer "API insurance" packages, where—in exchange for your premiums—they'd build and maintain API-compatible replacements for any and all services the insurance-holders rely on, if said services should happen to die. Then you'd just need to insist (with force) that all network-RPC-based "client" libraries have configuration to let you easily change their endpoints and expected X.509 trust anchors...