4 ways how to NOT decide the next tech stack

These are 4 really easy ways of making horrible decisions, but don’t worry, being able to recognize them is the first step to actually avoid them.

I just read this book from Francesco Strazzullo titled “Decision Making for Software Development Teams” and today I’ll brifely summarize about the 4 anti-patterns described in the first chapter of the book: hype-driven development (basically the latest shiny technology), the usual path (which I like to call “we’ve always done it that way”), the expert (or “trust me bro”) and rage-driven decisions.

Side note: I’m not talking about personal projects here, but about work related projects, there’s money involved. Sometimes a lot of money.

Well, I’m Leonardo, let’s get started!

The video

This time the video is slightly different than usual. I moved around a little bit, changing room and “tools” (you’ll see what I mean) for each chapter, I hope you like it!

If you prefer reading, you can find the script below.

Hype-driven development

The first anti-pattern is hype-driven development, the tendency to choose the latest shiny technology to solve a problem, even if it’s not the best fit.

Or at least, you have no idea if it will be the best fit, but you’re so excited about it. It’s the new technology so it must be better than the old one under any circumstances, right? Right?

This can also be seen on the other side, why should you keep using the old technology even if everyone is moving to the new one? Here the fallacy is… everyone, who? Do you have some data? Are they moving for a good reason which also applies to your case?

Because if these boxes aren’t ticked, chances are you’re just following the hype and your exciting irresponsible decision might end up backfiring you.

So, is hype always a bad thing? Let’s do a step back first.

The thing to consider here is that words like “always” or “never” shouldn’t usually drive your decisions. You know, in the tech industry we like to answer with “it depends”, so why would you use always or never?

Using a new and hyped technology might be a smart idea for example if you realize it can solve a problem you couldn’t solve with the current technology, however, you must be aware of the risks and the tradeoffs you’re making.

The usual path

In this unusual location, let’s now talk about the usual path, or as I like to call it, “we’ve always done it that way”.

How can we approach a new project? Well, let’s do it the exact same way we did it last time, it worked, right?

Yes, but the reasons why it worked the last time might not hold true on this new project. Some easy examples are having a tighter deadline, a different team or that specific technology going to the end of its life cycle or just not being the best fit for this new project.

A different definition of this anti-pattern is “Golden Hammer”, which is the tendency to use the same tool for every problem. If all you have is a hammer, everything looks like a nail, but sometimes you might need a screwdriver.

And after this terrible gag, let’s go back upstairs.

Get the book

By the way, I think you make decisions every day, right? From the technology to use, the libraries to install or the name of that variable.

It’s not just team leaders, but everyone is involved in the decision making process, all the way down to the junior developer.

For that reason, you can get a 5 dollars discount on the book if you buy it from this link.

The expert

Anyway, next up we have the expert.

Oh I heard a guy on YouTube talking about this new technology, hence it must be the best choice for our project.

This is clearly not a valid reason, but let’s make it a little more tricky: what if the expert is an actual skilled professional in the field? They can work on a consultancy company or they can even be your colleague from another department.

Should you follow their advice blindly? It’s obvious that the answer is no.

While there’s often a small set of technologies that might be the best fit for a given problem, there’s usually not a single best choice. There are always tradeoffs to consider and the best choice for a given project might not be the best choice for another one. Asking an expert is a good idea, but you should make sure he’s aware of the context and your specific situation, otherwise their advice, even if given in good faith, might not be the most appropriate.

A better use of an expert’s advice, instead of letting them decide for you, is to ask them to bring on the table the full set of options with pros and cons, so that the team can make an informed decision based on the actual context.

Rage-driven decisions

The last anti-pattern for today, is rage-driven decisions, which are those ones you make after a bad experience with a technology. At first, it seems obvious: the last project had so many troubles because of this technology, so let’s never ever use it again.

Doesn’t it sound familiar? It’s the exact opposite of the usual path anti-pattern, it didn’t work last time, it for sure won’t work this time too.

But wait, are you saying that relying on previous experiences, be them good or bad, is a bad idea? Not at all!

The key here is to make sure that a feeling of the previous experience is not the main driver of your decision. Either the previous experience was good or bad, you should always try to understand the reasons behind it, and then evaluate if they apply to the current project.

Why did it fail? Why did it succeed? You’ll probably find out it wasn’t 100% on the tech stack.

Conclusion

And that was it, 4 anti-patterns to avoid when making decisions.

Let me remind you once again that if you’re interested in this topic, you can get a 5 dollars discount on the book if you buy it from the following link: https://leanpub.com/decision-making-for-software-development-teams/c/dev-leonardo

I hope you liked this video, subscribe if you haven’t done yet, and see you in the next one!