You either die a hero or live long enough to see yourself become the villain.
You either die a hero or live long enough to see yourself become the villain.
It is about legacy code and the lifespan of our programs.
Lifecycle
Our programs are not forever. But what is the time that it should be renewed?. Usually, it is 3 years, some companies adopt a 2-year cycle, but it is hard to follow it. However, commonly, the 3 years is extended to two cycles (6–7 years). Our programs should not outlive more than this.
Why?
It is the lifecycle of PHP
- 7.2 up to 2019
- 7.3 up to 2020
- 7.4 up to 2021
It is around 3 years. PHP had a bumpy ride from 5.x to 7.x, but now it is quite stable. However, it had several changes, and it will have more modifications in the future.
PHP 5.6 was launched 6 years ago, and it was discontinued years ago. And yet (according to w3techs)
- PHP is used by 78.9% of all the websites.
- Version 5 is used by 35.0% of all the websites.
And yet, it doesn’t show the whole picture, for example, intranet systems. In any case, PHP 5.6 is still alive and kicking.
For the record, from all versions of PHP 7.x
- Version 7.2 33.3%
- Version 7.3 27.8%
- Version 7.0 13.7%
- Version 7.1 13.3%
- Version 7.4 11.9%
So, only a few systems use the latest version of PHP.
Why is PHP 5.6 still alive?
Why not? PHP 5.6 is slow (in comparison with PHP), and it has some vulnerabilities around here, but other than that, customers are pleased with the result, so they don’t need to invest in changes for something that they will receive so little in exchange.
Security
Upgrade Or Else…
Security is commonly used as a treat, “or your upgrade or else…” But usually, it doesn’t work. In any case, it is possible to ensure a safe system using PHP 5.6, so this argument is really a treat.
For example, you bought a car, and in 5 years somebody says, “you must toss it and buy a brand new car because it is safe.” However, you recall yourself and say, “but it is working well, and it is safe.” Maybe it is wrong, but it is what most people think: “if it is not broken..”
Developers
For developers, it’s easy to say, “you should upgrade!”. Mainly because they earn with it, they don’t pay for it. But somebody must pay for it, and if the system is big or complicated, it could cost a lot of money and time.
So it is the reason why developers don’t do the call about when to upgrade.
The shiny new thing
But even if we upgrade our system, we are not forced to use the new shiny thing. For example, some developers jumped from PHP 5.6 to 7.0, and you know what. PHP 7.0 is already discontinued (even after PHP 5.6). PHP 7.0 was so new and experimental, and some functionalities were discontinued in months. If we use new features, we could adopt and embrace technologies or features that it could be discontinued in a snap.
So, we could (in the possible) upgrade our system, however, it is different from using every new feature just because it is new.
For example, type hinting in PHP
function enroll(Student $student, School $school) {
echo "Enrolling " . $student->name . " in " . $school->name;
}Technically, it is not hinting; it is validating. Every time we call the function, it validates the type. It could affect the performance if it is used in a vital and recurrent operation. Do we need type hinting? Not really, PHPDoc could do the same work with the IDE without validating each time the function is called.
Updating vs Upgrading.
There is a big difference between updating and upgrading. Updating usually involves fixing bugs or adding new functionalities. Upgrading involves doing a revamp of the system, and it is not rare to rebuild the system from scratch. Sometimes, it’s easy to start from zero rather than upgrade an existing system.
TDD to the rescue
Well, not really. Our programs don’t work isolated in the world, and even if our system passes the test, then it doesn’t mean that it is bug-free. Why?
- The set the test usually is not complete. It could have 100% coverage, but it doesn’t mean that it covers all the cases.
- Part of the functionality is not in the scope of the test — for example, the browser, the database, etc..
Legacy Code
Sooner or later (if we don’t kill our code), our code will turn into legacy code. Legacy code is a code that is a dead-end. We could not upgrade anymore, and sometimes we could get so little for it.
Once it is in “legacy mode,” then or we kill it, or we continue doing support (in the possible)
For example, PHP allows (with a lot of work), to move from PHP 5.6 to PHP 7.0 with some little effort, but it is a challenge to move from PHP 5.3 or PHP 5.4, especially if you are using legacy libraries and they are stuck with it.
