5 Rules for Using Shiny New Technologies
Photo by Selecting technologies is hard. As a responsible software engineer, you may sometimes wonder: "is it okay to use this technology for this project?".
In our context, shiny objects are all things you don't know well, regardless if they are new or old. Examples include programming languages (hello Go!), frontend frameworks (hello Svelte!), hosting Options (hello Kubernetes!), tools, processes, and much more.
Sometimes it is okay to give in to shiny object syndrome
Shiny objects can pose problems from two sides. At the beginning of a project, you evaluate new technology but are not sure if it is the right decision to use it. The faster you decide, the faster you can do other important tasks.
Later in a project, a problem appears when you have used new technology, but it turned out that it was a bad idea. A technology could turn out to be a bad choice if there is something you need that the technology doesn't support. Or because using it correctly takes much more learning and research time than expected.
This is a problem of unknown unknowns
When you evaluate a technology, you know things about it, like its API and its marketing page info (known knowns). You also know some things you don't know (known unknowns), such as the scaling behavior of a new message bus.
Then, there are unknown unknowns. The things you don't know that you don't know them. Dan McKinley made a great explanation of this in his Boring Technology Article. Unknown unknowns are those nasty little (or big!) things that mess up your whole schedule and destroy your plans. With new technologies, both the number of known unknowns and the number of unknown unknowns are higher than with your current technology.
But that does not mean that you should never use a shiny new technology in your project. When are shiny objects safe to use? For me, there are three scenarios.
Rule #1: Shiny objects are okay when they are a small part of your tech stack
The significant risk with these unknown unknowns is that they mess up your whole schedule.
When time is crucial for your project, you can reduce that risk by limiting the number of new things in your project. For me, this limit is around one to two major new things per project.
But! Don't forget that new business domains or a demanding customer also count towards the "new things" limit. It also is a risk to your schedule when you need to learn a new business context or when things not yet running smoothly with your customer.
For time-restricted projects, you should use every advantage you have, to minimize unwanted surprises and increase your chances of success. It is useful to learn new stuff, but don't overwhelm yourself when you already have a tight timeline.
When you can, try out new technologies. Learning new things helps you and your team to stay sharp.
Rule #2: Shiny objects are okay when you do something for yourself
For many personal projects, my goal is to have fun and to expand my skills.
For these projects, use whatever you want to achieve whatever you want, free from your other requirements.
Be clear about your goal. If you want to learn, use as many shiny objects as you like. But if you're going to implement something that should be working fast, use the tools you know and restrict your shiny new technologies to one or two.
Rule #3: Shiny objects are okay when you have a specific goal that you want to achieve
This rule is a generalization of the previous two rules. Shiny objects are okay if you are clear about your goals with the project itself and with the shiny object you want to use.
You're safe to use a new technology or process when it serves a specific purpose. Keep focusing until you reached your goal.
Rule #4: Shiny objects are okay when you focus and don't get distracted
Don't get distracted by new shiny objects! You brought in that particular solution to help with one specific problem. Don't abort until you know if it works or doesn't work.
With a specific goal and good focus, you should be able to minimize the risk associated with that shiny object.
Rule #5: Shiny objects are okay when you involve your team
It is unfair to make a big decision without talking to everyone involved. Depending on your team size and structure, and the nature of the shiny object, different ways of talking might be okay.
If your organization has specific rules for bringing in new technology to a project, you already know what to do. If your team is based on trust, you also already know what to do - decide for yourself or bring in someone else to discuss it. And in all other situations: if you're unsure if you need to talk to someone, you should speak with someone on your team about it.
Conclusion
Shiny objects can come in many shapes. Whether you think about using a new framework, a hosting option, or a whole new process, keep in mind that there are always unknown unknowns.
TL;DR: when you evaluate a shiny object, keep the five rules in mind:
- Reduce your risks by using shiny objects only when the project itself is not challenging enough. And then also limit to one or two shiny objects.
- When for personal use: shiny things all the way (if your goal is to learn)!
- Set a goal before using a shiny object
- Focus. Don't get distracted by new shiny objects!
- Talk with your team about it