There are valid reasons most developers don’t like working with old or outdated technology.
One of those reasons is that they don’t get a chance to learn new technology and that makes their skillset less valuable on the market. If your company is still stuck with Java 6 and Spring Framework 3.x when Java 9 and Spring Framework 5 have been released, or stuck with PHP 5.x and Symfony 1.x when PHP 7.2 and Symfony 4 are out, you’re at least 5 years behind. And 5 years is a long time in the fast-paced industry of software development.
Even worse, if your company is 10 years behind the technology, your developers’ skillset is so outdated that it’s going to be much harder for them to find a decent job on greenfield projects. It’s likely the only jobs they’ll get will be maintaining legacy systems like yours. And they’ll get stuck there and get their skills outdated even more. That’s a vicious circle. (Hello, COBOL developers. 👋🏻)
Not My Problem
If you think that means it’s just a developers’ problem and you should not really care about that, you’re wrong. Since passionate developers enjoy keeping their skills up to date, sooner or later they’ll leave your company and go join a startup that uses current technology to be able to keep their skillset current.
Once all the passionate developers leave, the only developers you’ll be left with will be indifferent nine-to-fivers that just collect their paychecks and don’t even touch a computer outside of the office. And that’s not a good situation for your company to be in because it’s the passionate developers that are the most productive.
Founders of new and exciting projects tend to pick the latest technology. (Let’s not consider hype at the moment.) They want Java 9+ and Spring Framework 5+, or PHP 7.2+ and Symfony 4+. And when they hire, they look for developers with experience in those technologies. They want to hire passionate developers that stay up to date with technology and keep honing their skills. And those indifferent developers who are stuck with 10+ years old technology don’t exactly match that criteria.
Of course, if they are unable to find passionate developers, they’ll settle with the idea of hiring someone with a lot of experience with outdated technology in the hope to bring them up to date. But I don’t believe that a developer who was fine with being stuck with outdated technology in the first place will magically start caring about staying up to date.
Never Ending Cycle
Now, even if a new and shiny startup starts with the latest technology, if they’re developing a monolith application, the same will happen to them. The technology that’s hot today, will still be outdated 5 or 10 years from now.
The main reason monolithic systems get stuck with the technology they start with is that it’s damn scary to upgrade millions of lines of code to a newer technology or even a newer version of the same technology. Especially if you don’t have almost full automated tests coverage of the system.
When you don’t have a huge battery of automated tests, the saying “if it works, don’t touch it” does apply to you.
And even if you do have full test coverage of your system, upgrading to the latest technology might be just too much effort and hence cost prohibitive. I don’t see many companies eager to invest millions of dollars into upgrading their system to the latest technology, especially if it means their developers have to stop churning out new features. And the more millions lines of code a system has, the longer and more expensive it is to upgrade.
This way the cycle repeats itself and a startup that started with the latest technology is stuck with outdated technology no passionate developer wants to work with.
A microservices architecture solves this problem by definition because most services tend to be pretty small. Even though there’s no limit on the number of lines of code a service has to have to be considered a microservice, it’s hard to imagine a microservice having even a million lines of code, let alone millions. Of course, it’s possible that one or two services out of a hundred can have that many lines of code, but it should be pretty rare. And if it does happen, you should consider breaking that service down into smaller ones.
Even though the latest microservice I have developed was implemented in Java 8 and Spring Framework 4, the next microservice will sure be on Spring Framework 5 and maybe even Java 9. Yeah, it’s that easy. Nothing prevents me from starting a new microservice with the latest technology.
And when it comes to upgrading existing microservices, I don’t have to do that right away. If a microservice has stabilized and no one has to touch it for years, I don’t really need to upgrade it to the latest technology. I’ll just keep it as is until a time comes for the microservice to be revisited by adding new features or modifying existing ones.
When that time does come though, I’ll have two options. If it’s fairly easy and straightforward to just upgrade it to the latest technology, that’s what I’ll do. If, on the other hand, it will be too much hassle, I might just rewrite it from scratch using the latest technology. As a nice side effect, I’ll be able to run both versions in production at the same time to give time to developers of other microservices to integrate with the newest version. After that, I’ll just retire the previous version.
And the passionate developers you already have in your company don’t have to leave anymore. Just let them start a new microservice using the latest technology, and they won’t have to join a startup just to keep their skillset up to date.
It’s a win for everyone.