How Old Is Old

Not only is what's old new again, what was once new gets old. And it seems like it gets old faster and faster. When I got my first paying job writing software 30+ years ago I was using FORTRAN77, and it was a 10 year old standard that was in the process of being updated. When I left that job Fortran90 was the new hotness, and we were just starting the conversion process. We were just starting to play around with ANSI C, and C99 was just a gleam in someone's eye. There were some commercially available FORTRAN libraries for complex math and statistics that we used and got occasional updates, but big changes were rare.

Fast-forward a few years to Microsoft. Box products with a 2(ish) year update cycle, and updates were evolutionary. As I've mentioned, Flight Simulator was backward compatible to the beginning of time, as were Windows and Office. Yes, the UI would change and people would get upset, but there weren't a lot of fundamental changes, and no-one needed to throw out all the work they'd done and translate to a new system.

Things are a little different now. Frameworks for all sorts of things keep popping up. UI, Deep Learning, Parallelization, Datacenter Management (on prem and cloud). 5 years ago when I came to Uber Mesos/Aurora was the new hotness, and was going to replace a bespoke in-house service placement and management system. Here we are 5 years later and CoreBiz is hoping to finish that transition to Mesos/Peloton so they can switch to Kubernetes.

Not my usual area, but sometimes I get pulled into working on UI stuff. Angular, React, React-Native, Node, Deno. Which one should you use? If you're using one, should you switch to a different one? Maybe. Or maybe you should stick with whatever you're using.

Just because something is "old", whatever that means, doesn't mean you should stop using it. Working is a feature. A really important one. The thing is, it's easy to say "Time to change", but making the change is hard, takes time, and blocks other changes.

That doesn't mean you should never change, just that you need to count the cost before you do. And you need to measure not just the cost of making the change now, but also the cost of making the change later or never. And what the benefits of making the change now or later are. Because very often the short term cost pushes you one way, but the long term cost pushes you the other. And knowing which is more important can play a big part in your decision.