Over the course of my career I’ve encountered this too many times.
Application rot.
What is Application Rot?
I’m currently performing a detailed code review on a client system. It’s 2022 and I’m finding security packages dated from 2011. Packages that have been deprecated for years, still in use.
Visual Studio is screaming at me about them. Yellow exclamation marks everywhere I look. Nuget is kindly offering me the updates.
Some packages are so old, the latest versions available are dated 2015. Of course they are also deprecated, even these updates are 8 years old now. EIGHT YEARS …
Let that sink in.
This is an in-production product being sold and used, right now, by FT500s companies all over the world.
The yellow exclamation marks have been staring the old developers in the face for 7+ years … they did nothing about it. They didn’t even inform THEIR client that this work needed doing, or it wasn’t being done.
Nothing. Complete radio silence.
I personally find this staggering. It’s nothing short of professional misconduct in my opinion.
Why are so many developers terrified of updates? They even have Nuget to do a stack of the heavy lifting for them. Is it pure incompetence? Lazy?
Why Allow Application Rot
Applications left to rot like this are ticking time bombs. Not least of all it makes life for me a bloody nightmare picking apart all the dependencies and figuring out a path forward.
It’s no different to leaving a DIY job unattended for years, the problem just gets bigger and bigger over time on a logarithmic scale.
JavaScript Hell
From all the analysis I’ve seen and read over the years this seem endemic. Eye-watering numbers of web sites are serving up vulnerable versions of all kids of libraries.
It seems the mean lifespan is a package remains in use for 4 years after a vulnerability is reported. That’s a terrifying statistic.
Penetration Testing
We’re alright!! We’ve been pen tested!!
OK. I’ve gone through several pen test processes over the years and have regularly identified things they have missed or not reported on. This also depends on what level of service your client purchases from the pen-testing vendor.
It can be very thorough or it can be a box-ticking cursory rubber stamping effort.
Apply Your Updates!!!
The upshot of this is that as consultants and developers, we all need to do better on this topic. What seems like an easy route out now – do nothing, just turns into a bigger nightmare down the road, maybe not for you but somewhere out there, a developer dies every time you ignore an update …
Tut tut …
Over the course of my career I’ve encountered this too many times.
Application rot.
What is Application Rot?
I’m currently performing a detailed code review on a client system. It’s 2022 and I’m finding security packages dated from 2011. Packages that have been deprecated for years, still in use.
Visual Studio is screaming at me about them. Yellow exclamation marks everywhere I look. Nuget is kindly offering me the updates.
Some packages are so old, the latest versions available are dated 2015. Of course they are also deprecated, even these updates are 8 years old now. EIGHT YEARS …
Let that sink in.
This is an in-production product being sold and used, right now, by FT500s companies all over the world.
The yellow exclamation marks have been staring the old developers in the face for 7+ years … they did nothing about it. They didn’t even inform THEIR client that this work needed doing, or it wasn’t being done.
Nothing. Complete radio silence.
I personally find this staggering. It’s nothing short of professional misconduct in my opinion.
Why are so many developers terrified of updates? They even have Nuget to do a stack of the heavy lifting for them. Is it pure incompetence? Lazy?
Why Allow Application Rot
Applications left to rot like this are ticking time bombs. Not least of all it makes life for me a bloody nightmare picking apart all the dependencies and figuring out a path forward.
It’s no different to leaving a DIY job unattended for years, the problem just gets bigger and bigger over time on a logarithmic scale.
JavaScript Hell
From all the analysis I’ve seen and read over the years this seem endemic. Eye-watering numbers of web sites are serving up vulnerable versions of all kids of libraries.
It seems the mean lifespan is a package remains in use for 4 years after a vulnerability is reported. That’s a terrifying statistic.
Penetration Testing
We’re alright!! We’ve been pen tested!!
OK. I’ve gone through several pen test processes over the years and have regularly identified things they have missed or not reported on. This also depends on what level of service your client purchases from the pen-testing vendor.
It can be very thorough or it can be a box-ticking cursory rubber stamping effort.
Apply Your Updates!!!
The upshot of this is that as consultants and developers, we all need to do better on this topic. What seems like an easy route out now – do nothing, just turns into a bigger nightmare down the road, maybe not for you but somewhere out there, a developer dies every time you ignore an update …
Tut tut …