End of Life: Coping with the Death of a Technology
In 2019, Microsoft announced that Visual Studio 2019 will be the last major version with load testing functionality. They have depreciated their load testing tools and have shut down their cloud-based load testing services on Azure Pipelines/Portal. The simple reason Visual Studio Load was depreciated is because the tool wasn't growing in popularity and the market has numerous other options. I imagine Microsoft's time and resources would be better spent elsewhere, especially for cloud-based testing.
I personally used the tool on 3 separate consulting projects, and became very comfortable with the tool. Visual Studio Load was a clunky and rather limited tool compared to the market, but it was built into the .NET tech stack and has some of the easiest integrations I have ever seen for a project already utilizing Azure and Azure Dev Ops. I was able to spin up load testing on the cloud and have performance metrics report directly to an Azure Dev Ops dashboard for live and easy reporting.
I had to deal with the impact of losing Visual Studio Load, and learn how to better prepare for this moving forward. This post is not centered around performance testing, but rather the unique issues that arise when a technology is marked for End of Life.
The Impact
The immediate impact will be small as most technologies marked for End o Life will remain supported for some time. But new innovations, questions, features and bug fixes will slow down. The user base will slowly start moving away from a dying technologies and try to find something new. Some companies or user bases will decide to use this technology long term despite its deprecation. You will then have to decide if the short term gains of using a dying technologies are worth it.
There are a few questions you should ask yourself when one of your technologies becomes obsolete:
1. What do I have the depends on this tech?
This is probably the most important question you need to consider when a tech is End of Life. Is this a central technology for your architecture? Have many hours and resources been devoted to this tech? Will my system have to be written from the ground up after loosing this technology? Is it so vital no other tech will do?
Begin by understanding every integration and map these dependencies so you understand the actual impact. It's never overkill to document exactly how your systems or projects integrate and work together.
2. What other technologies exists that share a similar purpose?
Hopefully the market has a similar tool that could fit your use case. Look everywhere for alternatives and don't focus solely on the popular option. Keep your eye towards the future and see if the cutting edge might have the best tool for your job. Gather a list of strong options and scour the market for any news on the 'replacement' of your technology.
3. What makes my technology better and worse than the alternatives?
As you research alternatives, you will likely spot differences. For me one of the biggest pain points when switching technologies is losing out on your favorite features. Keeping a running list of differences will help make your decision easier as you review the alternatives.
Along with the bad should come some good. Find those new exciting features and theorize how helpful they might be within your system. Think critically about each feature and weight the pros and cons. This will help you balance out your options while keeping it focused on your specific use case. If a certain feature sounds nice but has no use for you, then looking elsewhere is advised.
4. What will the larger picture look like without this technology?
Looking at the larger picture along with the low level integrations is very important. How often are these alternative tech updated? Is there a large cost when switching to these new techs? Are there people skilled in these other techs, be it for hiring or question answering on forums? How new are these techs and will they stay relevant?
There are hundreds of possible questions, but the important thing is to think big after you start to narrow down the list. The best technologies out there will stand out when you consider the big picture.
5. How does the migration process look?
Some technologies make it very easy to migrate an existing system, and others make the process a nightmare. Easy migration and simple integrations are vital for some techs such as Application Security Tools and DevOps tools.
The impact from a tech reaching its End of Life can be big or small, but these questions should help you recover. There is a question that remains, "Can we prevent this impact?"
Going Forward
As technical people we all should know that our tools, and to some degree skills, depreciate in value. David Thomas and Andrew Hunt put it well in The Pragmatic Programmer, "Unfortunately, they're expiring assets." Andrew and David also dive into the idea of having a technical portfolio.
Andrew and David thought any technical person should manage their skills and tools like a stock portfolio, for which they call a technical portfolio. So what exactly is important for a tech portfolio?
You should follow these guidelines when managing your tech portfolio:
- Serious investors invest regularly
You should be managing your skills, tools and technologies frequently. Set S.M.A.R.T. goals to improve and add to your tech portfolio on a regular bases. Commit to learning a new programming language each year. Decide to get a certificate in a new Dev Ops tool every couple years. Both of these are just some examples that will help you invest in your own tech portfolio. You should try to add to your tech portfolio frequently to make sure you are always current. - Diversification is the key to long-term success
Learning a wide array of languages and technologies will set you up for long-term success. Putting all of your focus into a limited technical space is not ideal and could lead to stagnation. Learn multiple tools and technolgies and find their perfect use case. - Smart investors balance their portfolios between low and high risk investments
Just like stocks you want to have your technical assets spread out. The cutting edge often has risky and unexplored techs, but learning these risky techs can benefit you greatly if they become widely adopted. The converse of that is ignoring the highly popular and adopted technologies would be foolish. - Portfolios should be reviewed periodically
No technology is safe from becoming obsolete. Very few technologies stand the test of time and have a long life cycle. Your tech portfolio should be reviewed and old assets deprioritized. A portfolio full of out dated techs and skill is taking a major risk.
Doing each of these will not only build a personal tech portfolio, but also prepare yourself for End of Life announcements. If you consistently managed your tech portfolio an End of Life announcement is only a small inconvenience.
Final Thoughts
The 'death' of Visual Studio Load was a major impact for me, but I was already dabbling in other tools such as Jmeter and Load Runner. I decided to compare both Load Runner and Jmeter to the soon obsolete Visual Studio Load and find my preferred performance testing tool. I devoted time to adapting my current skills and knowledge, and now I am just as proficient on Jmeter.
Every tech will have an End of Life date, and it's up to us to prepare for that date by being connected and current. My colleague Robert Wroblewski and I recently gave a presentation on Improving Your Technical Portfolio if you would like to learn more.