Delve into the choices between working with cutting-edge technologies that may become obsolete quickly or established technologies that offer stability. Which approach aligns better with your career goals, and why?
Follow the DEVteam for more discussions and online camaraderie!
Top comments (5)
The important question to ask before adopting any cutting-edge technology is "Does this solve any problem which was very difficult/impossible to solve with stable/mature tech".
If the answer is yes, the follow-up question will be "How much effort will the new technology take to deploy to production" as cutting edge technology will move on a very quick release cycle, may still have sharp corners w.r.t deployment, observability, stability, security. It will require you to follow their release cycle closely. It can also be under documented and if you run into any unknowns, Stackoverflow may not be of help. Having well-reasoned answers to these questions can make it easier to sell the new tech to higher management and make them aware of potential dangers
I have LTS requirement codified in my corporate information security policies.
You only get an exception if the unstable build has new tech you’re specifically leveraging, and even then, we may stall rollout to prod until the feature moved into LTS
I'm a fan of LTS software (and hardware) myself. New tech, while interesting, has a tendency to go nowhere or suddenly break one day...or both. The history of computing is littered with a ton of stuff that lacks any meaningful product support. I know several companies that just play with fire, constantly rolling out and rolling back changes and features. Those entities drive me nuts with the constant stream of global breakages.
A few years ago, I wrote up a set of Compatibility Policies for CubicleSoft:
cubiclesoft.com/compatibility-poli...
Every developer should think about the software they write and release and then produce their own compatibility policies so that newcomers to any project can be on the same page. The above policies are, IMO, a fairly decent starting point for software compatibility and interoperability purposes.
It would be really interesting to see what your, probably lawyer-approved, corporate IS LTS policy reads like. It could be beneficial to others who might want to adopt a similar policy. I know that some employee/employer agreements are not supposed to be shared outside the organization, so I completely understand if you can't post that written policy here due to such limitations.
I have a copy of all the policies I've authored, stripped of IP for use as a portfolio item with job hunting, the specific policy referencing LTS can be found here: System Hardening Policy
It's simple, two sentences. Ignore the "Operating System" language, we interpret that broadly
Thanks. That's a bit different from a well defined compatibility policy as LTS can mean a lot of different things. However, just the LTS label alone carries the awareness of certain implied expectations (e.g. 3-5 years of support), which goes along with the overall intent to provide stability for the organization. Similar goals but different approaches.