The Dangers of Shiny Technology in Software Engineering
It’s Saturday night here. Tonight, I have a chance to revisit some articles in my reading list. The topic is, “using shiny, untested technology”. Here are a few of my selections:
- The Magpie Developer by Jeff Atwood in 2008.
we are too easily distracted by shiny new toys and playthings.
- The classic article “Why You Should Never Use MongoDB” by Sarah Mei in 2013.
- I’ve reread the article in 2020 to remind myself again. Sarah Mei is a thought leader in our industry. This article is gold. The thoughts there have somehow guided me in making some decisions in that era. For example, choosing between SQL or NoSQL database for my past web development works.
- Choose boring technology by Dan McKinley.
- The innovation tokens concept is interesting.
Every time I spin up a new project, I try to answer the following question honestly:
“Am I using this project as an excuse to learn some new technology, or am I trying to solve a problem?”
- Boring technology is awesome by John Hyland.
Summary: There are a few universal problems with new technologies that you can count on:
- APIs can change out from under you.
- They’re less secure.
- There’ll be fewer established standards.
- They lack basic tooling.
When to use shiny tech
- Side projects
- Internal tooling
- When it’s worth it
How to handle the hotness (if you must)
- Roll it out slowly.
- Standardize your usage of the new technology.
- The boring technology behind a one-person Internet company by Wenbin Fang
- Technology is usually just a means to an end. I’ve seen so many teams burn so much energy on complicated stacks just to drink kool-aid.
- Enough with the microservices by Adam Drake.
“Much has been written on the pros and cons of microservices, but unfortunately I’m still seeing them as something being pursued in a cargo cult fashion in the growth-stage startup world.”
Don’t even consider microservices unless you have a system that’s too complex to manage as a monolith. The majority of software systems should be built as a single monolithic application. Do pay attention to good modularity within that monolith, but don’t try to separate it into separate services.
– Martin Fowler
If you can’t build a well-structured monolith, what makes you think microservices is the answer?
You are not FAANG (Facebook, Apple, Amazon, Netflix, Google), stop trying to be them!
“Let’s use Kubernetes!” Now you have 8 problems by Itamar Turner-Trauring.
- “From chasing shiny tech to scaling too soon, beware these common missteps that can endanger your company”.
Hype Driven Development by Marek Kirejczyk.
Thinking The Impact Of Technical Decision by Didiet Noor.
What is the solution?
In my own opinion, focus on your fundamentals. Understand that, if your foundations aren’t strong and your fundamentals are not clear, then no matter what shiny new things you try to learn, it won’t help you for a long run. So, don’t ignore basic concepts before rushing to any new and shiny technologies.
Thank you for reading.