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 briefly 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 dollar 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!
Thanks for reading this article, I hope you found it interesting!
I recently launched my Discord server to talk about Open Source and Web Development, feel free to join: https://discord.gg/bqwyEa6We6
Do you like my content? You might consider subscribing to my YouTube channel! It means a lot to me ❤️
You can find it here:
Feel free to follow me to get notified when new articles are out ;)
Top comments (4)
Nice read Leonardo! I think this is a topic that doesn't get too much love in the developer community, although it's such an essential skill to master.
I'd also add that being aware of our own biases can really help as well. For example, asking ourselves questions like "Is my comfort level with this tool clouding my judgement?", "Am I secretly rooting for this tool to work?", "Am I comfortable accepting the risk of trying something new in my organization", "Will anyone challenge me on this decision?"...
I feel there will always be a level of unconscious factors at play, but if we try in earnest to think through them and mitigate them with our team, I believe our projects will be much better for it.
Hey Freddy, well said!!
Thank you for the comment and you're absolutely right, we should also be mindful of possible biases we might have... and most likely we do have, a lot! 😅
This is such an underrated article! I find myself kinda guilty here with the "hype-driven development". To be specific, I like trying out new tech stacks and seeing the experience.
Thank you :D
I mean, for a personal project where the goal is having fun and/or learning new things, following a the hype might make sense so you can also have a grasp of why is there hype in first place.
Going blindly with the latest technology in a work project that should run for years... is another topic :D