The problem with technology is that it keeps changing. New tools come out. New frameworks. New languages. New technologies. Some of them are good, but most of them are not. As cost-effective developers, we want to be using the best of new technology to accomplish tasks that people want faster and better than before. How do we figure out which new technologies are worth learning and adopting?
In my years of software development, I’ve found it extremely prudent to view the latest new shiny thing with skepticism. Keeping the hype at arm’s length can save you from a great deal of potential pain and frustration. Adopting a new technology too early or that ends up being inappropriate for your specific situation can result in a lot of cost and pain.
To a new developer, I say this: Be slow to adopt. Be wary of what is trendy. Be skeptical of a new technology’s alleged benefits. Take a moment to understand your current situation and tolerance for risk. Consider the potential long-term and ongoing costs. Think especially hard about the human cost, the cost of adoption of your team. Is the supposed gain worth the risk of building upon some cool/nascent/cutting-edge technology with an uncertain future? Would you be willing to do the hard work of supporting your usage of it if you were forced to? Making good technology choices early on and building solid foundations will dramatically reduce the lifetime costs of that software. Choosing a proven option, however boring it may be, is ultimately prudent and wise. Everything has cost, and not every system needs every possible benefit.
In this day and age, whether needlessly switching from a monolithic system to microservices-based architecture, rebuilding your frontend client in the latest JavaScript framework, etc., please consider whether or not the benefits are real and sustained and whether they are really going to be worth the costs of transition.
For example, ask yourself, by doing this, am I just moving spaghetti around on the plate? Is my system complexity really going to be reduced by this change, or by expending all this effort, am I only moving the irreducible hair of complexity around? In splitting up my monolithic system into a bunch of microservices, am I only moving coupling in my code now to coupling of my services, but now with a more complicated deploy process? Or by adopting this new framework with an uncertain future, am I going to be left holding the bag with some unsupported technology?
There are always theoretical benefits, but there are always real costs. Adding a new addition to your stack adds complexity to your system, your deployment, and your development. The extra layer of complexity is often costly in surprising ways. Ask oneself what will happen when things don’t work? How much pain will be added having to debug with an added layer of complexity? Am I willing to spend the time to deeply understand what’s going on underneath the hood? Or am I likely buying myself a much harder time of debugging? Frequently, it’s when things go wrong when a newly added layer reveals itself as a leaky abstraction.
It’s plain to see that the more simple things are, the fewer moving parts, the easier it is to debug and run experiments. Often overlooked, simplicity is frequently the smart and cost-effective option, so choose simplicity wherever possible. Quite simply, it often occupies the best spot on the trade-off curve.
Yes, on occasion, a new technology is worth adopting. But how do we determine this–how should we evaluate a new technology, library, or framework? You should evaluate it based on:
- How appropriately it solves your problem
- Its user base/community/ecosystem
- Its runtime performance
- Its stability and maturity and how much it’s been battle-tested for the real world
- The initial cost of implementation
The cost of maintenance over the life or your system or the lifetime that you’ll be supporting your use of this. Will this cause me more trouble than it is worth? In doing so, do not forget these five dimensions to consider (adopted from this source):
Lock-In. When I decide to move on to another option, how hard will it be to switch?
Opinionated Architecture. Can I do things in a way that best fits my needs, or do I have to conform to the new technology’s pre-canned approach?
Accidental Complexity. Do I spend my time thinking about my problem, or wrestling with the new technology?
Testability. Can I test my code easily, without excessive mocking?
Specific Considerations To My System. Am I now going to have to jump through insane hoops to achieve goals specific to my system?
At Zagaran, we don’t adopt a new tech just because it is new. We recommend to our clients not to throw out a well-proven, boring approach just to shake things up. Our recommended technology strategy is always to pick the best tools for the job and to minimize uncertainty and risk otherwise.
Nevertheless, as software development evolves, adapt. Be willing to learn new technologies when they pass your criteria and meet your specific needs. Expand your toolkit and stay current. But be cautious, be judicious, and remember, caveat emptor.