Avoiding Shiny Object Syndrome
Why that Hot New Framework Might be Bad for Your Business

The Temptation of New Technologies

In the world of technology, it's easy to get excited about the latest and greatest tools, libraries, or frameworks. As developers and tech professionals, we are constantly bombarded with new advancements, each promising to make our lives easier or more efficient. However, jumping on the bandwagon of that shiny new language or framework can often be more detrimental than beneficial, especially when it comes to enterprise software and established tech stacks.

Why We Fall for the "Shiny Object Syndrome"

The allure of the "shiny object" is strong. New technologies often come with promises of solving existing pain points in exciting ways. They offer modern features, improved performance, or simpler workflows that seem too good to pass up. It's easy to feel that adopting the latest tech stack will give your company a competitive edge or future-proof your software.

In addition, the tech community tends to talk about new tools non-stop—blog posts, podcasts, and social media discussions are constantly hyping up what's new. This constant exposure can create a sense of urgency, making you feel like you're falling behind if you don't immediately adopt the latest trend.

It's also just outright fun to implement a greenfield project with a new language or tool. Here at Jubulah, we are a team of curious builders. We find learning new things to be a fun and interesting part of our jobs. But building software is still a business, and that fun must be balanced with what makes business sense.

When Switching Tech Stacks Doesn’t Make Sense

While the temptation to adopt new technologies can be strong, it doesn't always make sense to switch from your existing tech stack, especially if your current setup is serving you well. Here are some reasons why:

• Existing System is Stable: We know firsthand that no system is perfect, so it might be hard to get a room of engineers to all agree that a current stack is "serving you well", but take an honest look at what you already have. If your current tech stack is stable, reliable, and well-understood by your team, there’s no immediate need to change. A new technology may offer theoretical advantages, but it might also introduce new risks and unknowns.
• High Switching Costs: Migrating to a new tech stack often comes with significant costs. These can include the time and effort required to refactor existing code, retraining staff, and dealing with potential compatibility issues. These costs can quickly outweigh the benefits.
• Vendor Lock-In: Some technologies are heavily tied to a specific vendor or ecosystem (e.g., AWS services, Google Cloud), and switching to a new stack could mean abandoning these integrations or incurring significant migration expenses.
• Lack of Talent: Even though a new technology may be popular, it might not have the same pool of experienced developers as your existing stack. Finding developers with expertise in emerging technologies can be challenging, which might make hiring and team growth difficult. (See extended discussion on this point below)
• Unproven Technology: New technologies are, by definition, unproven at scale. They might lack the maturity, robust documentation, or community support needed for enterprise-level applications.

When It Might Make Sense to Switch

While it’s easy to dismiss new tech out of hand, there are cases where switching makes sense. Here are a few scenarios where a change may be warranted:

• Performance or Scalability Limitations: If your existing stack is beginning to show signs of strain as your application scales, adopting a more efficient or scalable solution might be necessary. But, consider this after performing rigorous benchmarks and stress testing. You should also consider if similar performance gains can be achived with a smaller change (ex: optimizing the performance of your existing JavaScript vs a complete rewrite in go).
• End of Life for Current Technologies: If the technologies you’re using are being deprecated or losing community support (e.g., older versions of frameworks or libraries), migrating to a more modern alternative becomes a matter of future-proofing.
• Feature Availability: If the new stack offers features that are critical to your product’s future growth that are either not available at all in your current stack or offer significant improvements in user experience or operational efficiency, a switch may be justifiable.
• Long-Term Vision: If your company is undergoing a major overhaul or rethinking its architecture, it might be a good opportunity to migrate to new technologies that are better aligned with your future goals.
• Security or Reliability Issues: If your current stack is prone to security or reliability issues, this is a sign that something should be done immediately. Sometimes it's not the technology itself that's the problem, but rather the human behavior that stems from the design patterns in the tech. It's important to evaluate things from a behavioral development approach.

  For example, if the package management system encourages devs to install untrusted packages or if ecosystem packages maintainers consistently push breaking changes, then those behavioral deficits must be addressed. One path is implementing policies that effectively curb this dev behavior. This could be things such as increased security training, bringing 3rd party packages in-house, etc. If the design/behavior philosophies in the tech ecosystem are too strong for these fixes, then migrating away entirely is probably your best solution.

Things to Consider Before Switching Tech Stacks

When considering a switch, be sure to take into account these topics:

1. Assess the Impact on Current Workflows

Will the new stack integrate smoothly with your existing systems, or will it require major changes to your workflow? Evaluate how well the new technology will mesh with your team's processes and determine if it will disrupt productivity in the short term.

2. Estimate the Migration Costs

Understand the full scope of the migration process. How long will it take to refactor your codebase? What are the infrastructure costs? Don’t forget about indirect costs, such as training for your team or hiring new developers with expertise in the new stack.

3. Future Community and Vendor Support

Ensure the new technology has a vibrant, active community or strong vendor backing. Will you be able to find solutions to potential roadblocks? Consider the long-term support and adoption trajectory of the technology you are considering.

4. Evaluate the Talent Pool

Can you easily hire developers with the necessary expertise? Assess the availability of talent in the new technology. If it's still emerging, there may be a shortage of experienced professionals.

This is a nuanced point. Even with relatively less common technologies, such as rust or golang, there are still a lot of developers out there that already know these tools well. Some would also argue that the type of developer that chooses to learn and work with a language like Rust, is typically an above average developer.

It's the "easily hire" part of this point that is crucial. Can you hire a JavaScript developer reasonably easily? Absolutely. That's not an indication that JavaScript itself is good or bad, but rather a correlation with the vast amount of software projects that use JavaScript and TypeScript. On the other hand, if you are hiring for rust from a much smaller pool and a pool where most of the devs are in the top percentile of all developers, then your recruiting may be slower and hiring more costly. It still might be the right call to use one of these "less popular" technologies, but you should make your decision with eyes open to the details.

We frequently see leaders concerned over this ability to hire talent when selecting certain technologies, but to some extent what this translates to is concern over the ability to hire above median developers at below median prices. At Jubulah, we're strong advocates of hiring talented and curious engineers independent of whether or not they already know a given language. We hire people that first and foremost understand the fundamentals of software engineering. This means our people can relatively quickly learn and excel at a new language or tech stack, but this does come with added recruitment challenges as these engineers have a lot of potential career options to choose from.

5. It's Not "All or Nothing"

We've known engineers that are either Never New Nancys or Constant Change Charlies. The first group is always so scared of change that nothing new ever enters the company, while the second group changes so often that they release half the features of their competitors because they are always tied up in a code rewrite. In reality, this is false dichotomy.

Rather than migrating your entire application at once, consider starting with a smaller piece of your overall project. This allows you to experiment with the new stack without the risks associated with a full-scale migration. This is especially practical when using containerized micro services. In this model, consider switching a single service and then evaluate how it went. We've seen companies build out a new product with a language already well known inside the company only to have that project fail, and we've also seen companies successfully release their new app with an entirely new tech stack. The answer is not always obvious, so building in a space for rapid experimentation is a great way to land on what is the best fit for your organization.

6. Employee Job Satisfaction

Sometimes you might go with a technology that is "good enough" simply because it's more enjoyable to work with than the "perfect" technology. This might look like writing in a language your employees prefer even though that language's lack of efficiency in cloud computing will cost you more to run your software. As long as you are not cutting corners that impact safety, security, or regulatory compliance, the extra financial costs of going with the technically less optimal solution can be more than made up for by employee satisfaction, retention, and engagement.

Would you like help deciding what tech is best for your business?

At Jubulah Labs our philosophy is to select the right tool for the job at hand regardless of what technologies are currently creating the most buzz online. If you want help sorting through all the noise online, reach out to us for a free consultation about what tech stack might best fit your next project and how we can help you succeed.