We keep coming up with new ways to build software. Many of them are positives. Some of them are temporary setbacks. They are often new takes on things that have been tried before.
Sometimes it’s a joy to jump on that new framework, library or language. “Yes! Finally a better way of doing this!”
But often, you’ll have a bad gut feeling. “This was a bad idea years ago”, or “that sounds like a dead end” or simply “I don’t want to do it this way!”
As you get more experienced, you are more likely to have this negative reaction when you encounter new technology. Is it justified? How do you know?
Cycles
Technology runs in cycles, much like fashion. Things are reintroduced under different names. We go from CORBA to SOAP to REST to GraphQL (though distributed computing remains hard to get right).
Other things feel like pendulum swings: from thick clients, to thin clients, back to thick clients we go.
After you see a cycle or two, you start recognizing things that have been tried before. You’ll make judgements based on how that technology or technique worked the last time you saw it.
Scar tissue
Along the way you stub your toes on projects where technology does not work in your favor. This can be both good and bad.
You’ll learn the hard way that, say, scraping unstructured HTML using regex expressions is a bad idea.
On the other hand, you may also develop some poorly informed preferences. For instance: avoiding statically typed languages just because you used Java in a horrible environment (like working in early 2000s projects which cargo culted all the “Java Enterprise Edition” practices).
Time and immersion required
Some things can’t be clearly judged until you’ve sunk serious time into it. Most of us don’t “get it” right off the bat: we need practice and time before we can have an informed opinion.
For me, distributed version control was one of these. Git has a lot of sharp corners. It took time for me to really internalize the data model and feel confident in it. I was flailing around with memorized commands for years until I finally “got it”. I also know people who took a look at Git, said “NOPE!” and stayed away from it as long as they possibly could.
Another one for me is functional reactive programming. FRP is popular in the Android world via libraries like RxJava. I am still practicing it and trying to understand where it makes sense or not to use it. I still don’t feel like I quite get it — but this may be because I’m not fluent enough in it yet. Perhaps I just need to get over the “hump”, like I did with Git?
Bad idea today, viable tomorrow?
Another challenge is that underlying factors may change our idea of what works and what doesn’t. As we get more horsepower and better tools, things change. As a wise man once said: “New shit has come to light”.
At one point, we worked hard to avoid instantiating more objects than we had to in the backend. Over time, we had enough memory that object allocation became less of an issue (and then mobile development took off, and we were right back to careful memory management!)
You have re-evaluate regularly. “Maybe this dynamically typed language finally has proper tooling now? Let’s check in again and see.”
Sometimes it’s still a bad idea
While circumstances change in some areas, other things just seem to stay a bad idea decade after decade. This is where experience and scar tissue helps you. You’ll see problems approaching from a mile away because they’ve hurt you before.
“Maybe object relational mapping frameworks have gotten good enough that I can start using them in a care-free way in my codebase? Perhaps I can finally stop worrying about how my data is persisted? I’m sure this ORM framework won’t bite me down the line?” (Not likely, sorry).
Popular != Better
Another issue you’ll notice: fashion and herd mentality doesn’t automatically mean technology X is a good fit for your project. Just because everyone jumps onto a popular framework or language doesn’t mean that you should do so. A tool can be popular for reasons that map poorly to your needs.
“Everyone seems to be using Node. I guess we have to as well.” Or, it might be popular because it lets frontend developers re-use their skills and tools for backend development? Node isn’t the only game in town for event-based programming. If you’re already comfortable on the JVM ecosystem, you’ll do fine if you keep building on that.
“We need to use Java because that gives us a huge pool to recruit from.” Or, you could focus on picking a technology that fits your domain really well. You may need fewer developers if you do so. Maybe Elixir or Clojure or Go is a better match for your project? Bonus: while the developers in those communities are fewer, they are better motivated.
Give it a chance
So you’re having that negative reaction. “Forget it, this is not worth the effort!” Think it through: are you just unwilling to change and learn new things, or is your experience telling you something important?
Knowing the difference is a tightrope walk. You should steer clear of approaches you know in your bones are a bad idea. However, you also have to be willing to try (and re-try) things — even if you don’t like them up front.