Dot Net faces a number of Y2k events more frequently than ever. The number of releases of the Dot Net framework has been stepped up, sometimes as often as two in a single year. However, the number of previously released versions under active maintenance has not increased. This means that the code you write today will be un-supported in two to three years rather than five to 10 years. In short, get ready to spend a larger percentage of your time keeping existing code bases current with new versions of the frameworks you use.
Another Y2k scenario we are all familiar with is the looming end of life for Silverlight. Already there is a lot of effort to move software off of the Silverlight stack, and convert it to the more universal web platforms. Silverlight hits end of life in 2020. So, now we need to start converting our apps to Html 5, etc.
I’m sure this is just the tip of the iceberg. This is an issue with just about any third party component outside your control or release cycle. How are you managing the change? Is this something we just need to add to our regular budget? It seems like we are going to need, more and more, to contribute more time to keeping our code base current that we did in the past. I’m not just talking about upgrades to canned packages. I’m talking about frameworks and tools for performing work.
What do you think? Can you guess how much of your time is spend maintaining existing products simply because the tools or environments have changed, requiring modification to keep current? If so, why not share your experience in a comment?
Cheers,
Ben