
Old Code Gets Younger Every Year - mbellotti
https://medium.com/@bellmar/old-code-gets-younger-every-year-3bd24c7f2262
======
deckard1
> The real horsemen of the legacy apocalypse is the depth of the dependency
> tree.

I won't speak for Java or Python. For Node/JS, I do not see this being a
problem for the future. The reason is because npm is so fragile that the
entire thing falls over _today_ if you just look at it wrong. The very second
you run "npm install" you have a mountain of instant tech debt. The primary
reason for this is because the people writing JavaScript do not know what they
are doing. They have not cut their teeth on libraries in C/C++ or other
languages and have no clue how backwards compatibility or versioning works. If
you doubt what I'm saying, then I invite you to do your own quality inspection
of any major JS library or framework out there. I'm not going to name names,
but the vast majority of it is pure shit.

In my experience, JS code has a life expectancy of about a year and a half.
Give or take. After that, it is rewritten. Which also contributes to the lack
of quality in the JS ecosystem. There is a built-in assumption that this code
won't survive past the time your average dev gets bored of it.

People, today, do not realize there are JS frameworks that predate
React/Angular/etc. and _have already died_. Once popular frameworks. And I'm
not talking jQuery. You don't see them because JS development = churn. You
don't even see CoffeeScript mentioned today, and that was just a few years
ago.

~~~
Scottopherson
Almost every comment thread, regardless of topic, has someone shitting on
front-end developers and it's extremely demoralizing.

~~~
Sophistifunk
If you read that GP post as a personal attack, you might be identifying with
your tools. We all do it sometimes, but it's something we should keep an eye
out for because it's IMO the most toxic part of programmer culture, and a big
part of what's holding us back.

Almost all of my programming time these days is JS, and I've been doing JS as
long as anybody. I know what I'm on about, and I can tell you the JS+NPM
ecosystem as a whole is a hot mess. GP is not some crazy person with no idea
what they're on about. Well, they might be, but you can't tell from that post
:)

~~~
pldr1234
Please re-read the GP carefully: "The primary reason for this is because the
people writing JavaScript do not know what they are doing".

If that isn't a personal attack on a particular group of developers, then I'm
not sure what constitutes personal attacks.

Also, as a top-flight engineer working in a multi-billion company (and also
having worked with Java and .net professionally for many years), the JS/TS
ecosystem as a whole has never been better than it is today.

And TS remains my lang of choice today, for professional and personal projects
:)

------
Wowfunhappy
There's a fundamental question here which no one ever seems to ask: _Why_ is
the modern software industry in such a constant state of flux? Are we really
becoming so much collectively smarter every year, and if not, why did the
previous version of Software X make the wrong decision? Is there an end point
where we all actually figure out how to develop software properly?

As I see it, truly mature software should introduce breaking changes twice a
decade _at most_ , and ideally less often than that. I don't doubt that most
software updates provide a net benefit, but what of the inherent cost of
change? Changes require every single user to put in extra work, to adapt to
the new version's functionality. Why are software projects so cavalier with
their users's time?

And this applies to end-user software too, by the way. Every time Slack
redesigns its interface, users need to relearn where all the buttons are.
Nothing can possibly justify rolling out ten million redesigns; if a facelift
is in order, leave it in the oven for long enough to get it right, and then be
done.

~~~
thaumaturgy
It might help to think of the entire field of software development as a single
living organism that's clumsily, through trial and error, trying to grow into
maturity, to find the best way for software to go from concept to realization.

It's very young. Thousands of years passed between the earliest mathematics
and the first calculus. Software has had, at most, a hundred years.

Things like microservices, SOLID, dependency hell, npm are all examples of the
software organism trying to figure out what works in reality and what doesn't.
None of the individual cells -- us developers -- can get a big enough view of
the whole thing to understand ahead of time exactly what will work and what
won't in large scales and over long timelines. We might argue from some
ideology or personal experience, but we don't really _know_.

Software wants to be inexpensive, both in initial development and in ongoing
maintenance. But what does inexpensive really mean? Does it mean that it
starts with a formal proof that takes weeks to develop and then is cast into
code and never modified again, or does it mean a function that's banged out in
minutes and then has an entire suite of test cases written against it and is
maintained in minutes and hours here and there for years?

The software organism has learned some things it shouldn't do, but that
required lots of developers trying it out, and other developers wailing and
gnashing their teeth about it and altogether saying, "this is bad and it
doesn't work and we must do it another way!"

We aren't going to see software development reach maturity in our lifetimes. I
don't think it will happen for another hundred years at least. I think,
eventually, software might settle down to a handful of purpose-built
languages, and somehow all the problems of code reuse and distribution and
documentation will gradually get solved, probably over some massive and
absurdly complex network. Developers might become more like immune system
cells, wandering around the network and fixing up the little bits here and
there that they specialize in. I dunno. In any case, before any fo that
happens, we first have to find out why every other approach to software
development is worse.

~~~
d_tr
Besides the fact that software is a relatively young field, it also aims to
exploit hardware devices which have been evolving ridiculously quickly.

------
yoz
Quoting the article:

 _Around 60% of packages on npm have not been updated in a year or more.
Despite the lack of maintenance these packages are still downloaded billions
of times._

This is a problem across many other languages/frameworks as well. Many popular
packages have a single maintainer and the entry in the package manager index
is accessible only by that maintainer. If that maintainer stops paying
attention, the problems could be worse than the package just bitrotting, as
we've seen from supply-chain attacks like event-stream[1].

There are volunteer orgs like Jazzband[2] which take group ownership of
popular packages to ensure ongoing maintenance, but I've not seen many of
those so far.

[1] [https://www.hillelwayne.com/post/stamping-on-
eventstream/](https://www.hillelwayne.com/post/stamping-on-eventstream/) [2]
[https://jazzband.co/](https://jazzband.co/)

~~~
jedberg
Yeah, this is a big problem with pip. If you can't get the old maintainer to
add you as a contributor, you can't update a package on pip.

So now you have to fork it, come up with a new name, and then publish that
instead. And then hope everyone who depended on the old package switches to
your package.

Reddit had this same problem with abandoned subreddits. They instituted a
policy where you could apply to take over an abandoned subreddit, so if there
had been no mod activity you could take over.

Pip needs a process like that. They need a way to take over an inactive
project. Safety would be a big concern, you don't want someone malicious
taking over a popular but abandoned package and then hacking it. But safety
the other way is important too.

There is also the odd situation where you could end up owning the code and not
the package on pip. When my company acquired another, we got all their code.
We only realized later that we didn't get the credentials for pip. Luckily the
old owner was kind enough to just give us the credentials, but we could have
been stuck owning the code but not the pip package.

~~~
x1798DE
There is such a process, PEP 541:
[https://www.python.org/dev/peps/pep-0541/](https://www.python.org/dev/peps/pep-0541/)

It was adopted in March 2018, and many projects / names have been claimed
under this process.

You can see a list of some of the projects claimed or in the process of being
claimed here: [https://github.com/pypa/pypi-
support/issues?q=label%3A%22PEP...](https://github.com/pypa/pypi-
support/issues?q=label%3A%22PEP+541%22+)

~~~
Mattwmaster58
It's suprising what an email from PyPi admins can do. After many emails from
different people and countless GitHub issues over the past year, the only
thing that got a reply from the maintainer was an email from the PyPi admins.

------
_bxg1
> I’m just not inclined to agree that civil society can’t continue to run on
> millions of lines of COBOL for another 60 years. It certainly can.

> Java 8 and Python 2 on the other hand are a far more serious threat. When
> systems can’t get off end of life technology they miss security updates,
> performance enhancements, and new features.

This seems contradictory. Is it not also a problem that _COBOL_ hasn't been
getting security updates for years (I assume)? Are COBOL systems typically
isolated from the outside world in some way?

~~~
mech422
Sort of... COBOL programs are usually batch programs, and grab input from tape
rather then the net. Interactive stuff tends to only be run on internal
networks (3270 terminals used to be the norm).

~~~
_bxg1
Yeah, I wondered if it was something like that. Sounds like input is sanitized
before it even touches that system.

Which begs an interesting train of thought: could we make systems that last
longer by doing a better job of isolating pieces of them from the outside
world? If malicious input never reaches your code, does it even need security
updates?

~~~
mywittyname
The rubber has to meet the road. Users have to interface with the software.

"Backend" software tends to be very long lived because it's not client facing.
Clients don't care that the software was written in Java2 and uses some weird-
ass collection of korn shell scripts to keep things moving. These scripts
usually just need to eat data from one location, and poop it into another. And
because these systems are old, they are well tested and battle hardened.

But that backend is no good without some form of user interface. This is
almost always the place where things break down. There are many more people
involved in the decision making for UX, and we have more and more devices with
different use-cases. Most tech-ish companies can't afford to ignore completely
new computing paradigms for decades.

~~~
_bxg1
At the risk of stretching the metaphor, what I'm talking about are bearings
that separate the wheel from the rest of the car. Maybe you have a thin,
outward-facing server that does nothing but authenticate, validate, and
sanitize input data, and then redirects that to some internal system that
knows for sure exactly what it's going to get, and doesn't get to talk to the
outside world directly, and therefore doesn't have to worry about attacks.

~~~
giantrobot
Congratulations, you just invented "middleware".

------
wvenable
Some companies that have large COBOL code bases don't hire "software
developers" \-- they hire people who have worked in other careers and want to
switch to software development and then they extensively train them
internally. This could explain the median age of COBOL developers remaining
constant.

~~~
bryanrasmussen
what other careers do they prefer to draw future Cobol developers from?

~~~
wvenable
I worked with a former construction worker who was going through the training.
He saw this as his opportunity to get out of that kind of work. A lot of the
hires had non-technical and non-domain backgrounds.

------
jnxx
> The real horsemen of the legacy apocalypse is the depth of the dependency
> tree. Modern software development stacks abstraction on top of abstraction.

I think Python2 will be 2050's COBOL.

~~~
onei
> I think Python2 will be 2050's COBOL.

I expect otherwise. My company has various tools and applications that weren't
migrated to python3 and it's getting harder and harder to support then as
dependencies keep dropping support for them (someone had the bright idea of
not versioning dependencies). Sooner or later a nasty bug is going to be found
that makes continuing to use it untenable and you'll be forced to upgrade.
Python is still under development enough to make upgrading attractive.

If a language manages to become hugely popular and then stops development,
that's how you end up with Perl or COBOL.

~~~
cyberpunk
I know of at least 3 banks that use python2 inside their trading platforms
(the big two use python as the built in scripting languiage) -- which would be
a multi-year multi-10s-millions project to migrate to 3.. We won't be saying
goodbye for a while...

For standalone stuff, yeah, it's not so bad. Upgrading between node releases
has been more painful to me than python 2->3..

~~~
iso-8859-1
Wow! What are the problems you encountered upgrading Node releases? I noticed
how they _removed_ tail-call optimization, which broke Lamdu.

~~~
giantrobot
Pinned dependency X stops working in Node X+1. Upgrading dependency X to work
on Node X+1 breaks code using dependency X. Sorting out the mess stops
development and leads to cascading breakage.

So just say "fuck it" and wrap the project up on a Docker container running
Node X. Now work can continue. Luckily the project is internal so missing
security fixes is less of a problem than something customer facing.

------
awake
Python’s standard library is essentially a Swiss army toolkit for manipulating
data. It has email and imap parsing built into it! I’m sure this doesn’t
completely explain the dependency tree size but it does explain the
proliferation of simple packages in JavaScript. Even data structures are
difficult to find in JavaScript. Try looking on npm for a max heap. Python has
heapq built in. JavaScript has ten libraries that are all equally unpopular.

------
tehjoker
This is one of the better tech articles I've seen on here recently. The
analysis of why Python vs. node ecosystems vary in dependency depth and
breadth is good food for thought. Python has long been a "batteries" included
language whereas node has not. Node makes it easy to publish packages whereas
my experience with python is that it is quite difficult to get a handle on
doing PyPI (versus Anaconda!) the right way. Publishing wheels versus source
is confusing and it took me a while to understand the nuances. There's also
the idea of supporting python2 vs python3, which people from different
quarters will criticize no matter what approach you take.

Publishing binaries on Python is also difficult and a highly skilled endeavor
requiring additional knowledge of compiling shared objects, docker, and the
baroque manylinux concept. Once you have a system down, it becomes easy, but
that took me about 6-12 months of accepting increasingly complex requirements
before I could get a decent handle on it. I have not tried publishing binaries
on npm so I can't say what the relative experience is.

------
kbenson
Kinda surprised to not see Perl in there in some form, since it's still around
as the glue holding a lot of older systems together (and for new stuff, but
that's not the point of this article). Then again, it's got a little bit
different of a story, since most (almost all) the old Perl from decades ago
will run find on a brand new Perl interpreter released recently.

~~~
pinewurst
I have a Perl problem right now. It's not the Perl interpreter at all, which
as you say runs the old code fine. It's the hierarchy (read as "dungheap") of
package dependencies that have changed since the last primary software version
was installed.

~~~
kbenson
Well, the good thing is all those old versions of modules are archived[1] and
you can still get them if you really need to, and there are utils to spider
the dependency chain and tell you the packages and versions (and I think stuff
that will make sure those versions get fetched) on CPAN itself, so it
shouldn't be too hard to get the prior stuff up and running if you go that
route (even if it might have security implications). The only stuff it would
be hard to back down in versions would be core stuff, but I'm not aware of any
core Perl modules that have had breaking API changes.

1: [http://backpan.cpantesters.org/](http://backpan.cpantesters.org/)

Edit: Cleaned up an ambiguous sentence in the middle there.

------
jonnycomputer
As I once told an interviewer, "Legacy code is the future!"

------
mcv
I can't help but look at this from the other direction: why does code
constantly have to be updated? There's something to be said for something
that, once built, simply _works_.

People love plenty of old things: antique furniture, oldtimer cars, classic
books from centuries ago, monumental buildings. But software needs to be
constantly rewritten en updated, and that takes a lot of work.

On the one hand I don't want to make the case for outdated languages and
systems, but on the other, we are spending a lot of effort just keeping things
up to date with the latest technologies. Sometimes that's really necessary of
course; security holes need to be fixed, and frequently new features are
necessary. Better ways of doing things have been discovered or developed. But
man, there's a lot of effort going into these legacy systems.

Although I love learning new things, I also kinda hope that some day we'll
reach systems and languages that are so well-designed that they don't need to
be changed much, or at least keeping them up to date will become trivial.

~~~
Cthulhu_
It's because the landscape moves on. Take Windows applications; plenty of apps
were built for Windows 95 or Internet Explorer 6, but they no longer work in
newer versions of Windows or IE.

Companies are holding back on updating their users' browsers because they
depend on these applications. This leaves them with two options; invest to
have the application updated or rebuilt for modern browsers, or take the risk
of outdated and insecure software.

I guess it can work with sandboxing and virtualization and the like (how they
nowadays keep old mainframe applications working on modern hardware), but it's
a patch.

~~~
mcv
I know why it happens, but I still regret it when that means old things become
inaccessible. Old games become unplayable, or websites stop working (not to
mention that they are frequently unfindable on search engines), etc.

We treasure the writings of the distant past, but the 1990s are already
becoming surprisingly inaccessible.

For games, there's fortunately gog.com that tries to keep old games playable,
and archive.org of course tries to preserve old web content, but that only
really works for static content. And then there's all the cool stop-motion
lego animation I found before Youtube came along, and now I can't find them
anymore.

Internet sometimes feels like a city bulldozering their entire city center to
rebuild everything according to the latest standards. It's certainly
convenient, but you lose so much history.

But now I'm talking more about the loss of content than about the fact that
everything requires constant updating and is never _done_. These are two
different concerns, but I feel them both.

------
ChrisMarshallNY
I'm happy I found Marianne Bellotti. Good stuff. I'm following her now.

~~~
yoz
She has so many great pieces on Medium. It's worth looking through them.

------
nonsince
I know the Rust Evangelism Strike Force is a meme, but Rust genuinely has a
good solution to language rot with its "edition" concept, where the language
can be updated and the compiler just converts all code to a mutually-
interoperable internal representation. It’s not dissimilar to using something
like Babel for JS, except that because this internal representation is
extremely simple, it’s far easier for the language to change more, add
restrictions, remove restrictions, and so forth, while still being
interoperable. Sadly, Rust has no good equivalent when it comes to libraries,
and it’s not unheard of to have two libraries that should be interoperable
fail to compile because there’s no way to find a single version of a shared
library that satisfies both of their version constraints, even though the
actual types in question are identical. I’m not sure if the error messages
still look like this, but they used to say something like `expected foo::Bar,
got foo::Bar`.

------
czbond
A bit of fun - "That's what I love about this code, man. I get older, it stays
the same age”. “Alright, alright, alright.”

------
hinkley
> In all likelihood the reason the average age of COBOL programmers is stable
> is because COBOL programmers develop their depth of experience and expertise
> in other languages before moving over to COBOL later in their career.

No, it's probably that there's a steady but small influx of new developers
coming in and the bell curve is throwing off the 'average'. Lies, damned lies
and statistics.

Answering questions with statistics is a rookie mistake.

------
basscomm
_Young programmers do not have the option of learning COBOL._

The university I went to still offers COBOL classes.

------
stuff4ben
I'm banking on Java still being needed when I'm 65 (~20 years from now) and
close to retirement. When my 401k is worthless, I'll still be able to make a
living until I'm dead and buried. Seriously though, Java is the COBOL of
tomorrow.

------
dsdklfjskldj
Meanwhile, Android still doesn't fully support java 8.

~~~
_old_dude_
> from the TFA, The end of life for Java 8 was supposed to be 2019

Nope, that the EOL of the free support of Oracle JDK 8.

Currently, the OpenJDK 8 is maintained mostly by RedHat, so EOL of Java 8 is
at least 2026 [1]

[1]
[https://access.redhat.com/articles/1299013](https://access.redhat.com/articles/1299013)

------
ncmncm
She found plenty to talk about without even mentioning the Lava Flow anti-
pattern.

Her other essays are also insightful. The one about Steve Jobs is the best
about him I have read, even considering Isaacson.

------
netcyrax
Couldn't read the article because I've "read all of your free stories this
month". I would prefer a few ads rather than the Medium's garden.

~~~
Sophistifunk
I suggest you get a "Cookie Autodelete" browser extension. Not for Medium per
se, but if you have one this problem also goes away.

