Why You Shouldn't Blindly Follow Tech Trends

Use a trend-sifting framework instead

Why You Shouldn't Blindly Follow Tech Trends
Photo by Slava Taukachou / Unsplash

We're attracted to tech trends like drug-addled maniacs. We know it's wrong, but we're powerless to stop.

Jeff Atwood refers to the phenomenon as the magpie effect.

I've often thought that software developers were akin to Magpies, birds notorious for stealing shiny items to decorate their complex nests. Like Magpies, software developers are unusually smart and curious creatures, almost by definition. But we are too easily distracted by shiny new toys and playthings.

That was me. Years ago, as a junior dev, I often pushed the team to adopt the latest tools and tech.

The team – primarily comprised of age 40+ developers – welcomed my excellent suggestions, like a case of herpes.

On reflection: I understand. The team were institutionalised; scared to challenge the status-quo.

The tech landscape was a ball of spaghetti. It had grew organically as the business scaled. We built everything in-house and were lucky to have a sociopathic lead with zero patience.

I didn't care. I felt caged. Shackled to shit tech.

I was young, keen but naive. I didn't consider the big picture. We weren't a tech company and certainly weren't trailblazers. Adopting bleeding edge would have left us bloody.

Don't Believe The Hype - Public Enemy

Think objectively; problems are always nuanced

Fast forward 5 years. I'm working on a project for a finance business to replace a customer portal.

I'm in a workshop with several UX designers from a partner agency, discussing the journey for an investment calculator.

Me: "We need a disclaimer stating that the calculation is indicative so we comply with the regulations."

UX lead retorts sharply, "No! We need to focus on user needs".

Her flock of like-minded colleagues nod in agreement.

I was furious. I won't go into detail, but my reaction was far from stoic.
Later, after I'd calmed down, I replayed the events in my head. Questioning my sanity. Was it me? Were they right?

They were right. Yet, fundamentally wrong.

Yes, 'user needs' should be at the forefront of your mind when designing a journey, but you still need to consider constraints. Moreover, you need to use common sense! Otherwise, it's not a viable journey. It's blue sky bullshit.

I see it all too often in tech engineering. An engineer reads something like "NEVER use click-ops; use infrastructure-as-code (IAC)".

Again – yes, I agree in the right context. If you're building enterprise software with a team of engineers, you should use IAC. However, using click-ops when building a spike is OKAY. It’s a spike!

one-size-fits-all solution may not be effective because each problem has its unique context and specific circumstances that must be understood and addressed appropriately.

Key point: think objectively – from multiple perspectives. Each problem has a unique context and specific circumstances you can't solve with one-size-fits-all solutions.

I'm a cynic, a sceptic, and I have a nose for bullshit — all thanks to my 10+ years in corporate IT.

Applying my learnings from corp IT, I use this 3-step system to evaluate if a trend is worth my time.

1) Don the commercial hat (30 mins)

I'll ask myself:

  • Do we need it; what value does it bring?
  • What's the learning curve; how long will it take the team to get up to speed?
  • What's the catch; are there any negative consequences moving forward?
  • Who are the competitors, and how do their offerings compare?
  • How much will it cost – now, next year, and in five years?

2) Research (30-60 mins)

If the commercial answers are broadly positive, my next step is researching. I prefer reviews by independent authors who aren't biased and speak objectively.
As a cynic, I'll scour for contrarian views – arguing against the hype.

3) Test Drive

Finally, I get hands-on and evaluate the tech, tool or technique.

If it's a technology or feature: I'll explore for a while. It's fun, and helps build a mental-model of how everything slots together.

Once I've finished exploring, I'll try building something that solves a problem – work or personal.