We need to pick the right tool for the job
This is a sentence I've heard countless times over the years, and it is often followed up with the corollary "If all you've got is a hammer, everything looks like a nail". There is a lot of truth and depth to these statements!
However, each time they come up, it never really becomes a platform for having an objective discussion about which tools could be considered right for job in question. Rather, it turns into each developer insisting on their preferred hammers, regardless of what the job actually called for:
Picking what we know
In a recent project, I was put in charge of, I laid out all the reasons why an N-tier solution with a React frontend would not be a great idea:
- Added complexity in the UI layer, when it wasn't needed. HTML without JS would do just fine
- Added maintenance burden of managing a JS frontend and a C# backend
- Added operational costs and more complex deployment scenario, since there would be two apps to keep in sync (frontend JS app and backend data API)
- Volatility of the JS ecosystem, needing constant updating and patching forever
- ... I could go on forever
The discussion with the solution architect got a little heated, where I argued for simplicity, efficiency, web standards, and no nonsense; the main argument from the opposing side was: Well, we don't have Razor Pages developers, but we have a handful of React developers on staff, so let's just pick what we know.
Picking what we know is not a sin. It is certainly better than sailing into unknown waters, but maybe we should simply staff the team with people who are capable with the tools that the project calls for instead?
It resembles the sunken cost fallacy: We already hired a bunch of React devs, so we might as well throw React at every single problem now.
Exploring new things
Another situation in another project flips this on its head. Rather than arguing for using what we know, the developers argue for using this new tech, that we're not really familiar with yet, but sounds really cool. How can we argue that a tool is fit for the task, when we don't know the tool yet? We can't, obviously, so staking the success of the project on new, unproven tech sounds dangerous.
And sure enough, the project pulled in Blazor as a C# alternative to React, but upon review of the project, it is clear that the developers are stepping right into all of the classic pitfalls, because they haven't had the chance to learn the tools properly, and suddenly the project deadline approaches and things need to simply be done.
The case for boring tech
As a developer, I am always curious about new tech, and wanting to give it a try. Being able to learn on the job by being given permission to use new stuff for a project is super fun and educational and really scratches that itch, but ultimately, it is irresponsible and a big gamble on company (or client!) money.
Using tried and true technology isn't as fun and interesting, but will yield a more consistent quality. Additionally, staking projects on tried and true tech is safer, and gives the teams the opportunity to buy into a stable platform and start sharing libraries, tips, and tricks so future projects might run even better.
I have 10 years in the software developer industry, so it is too soon for me to be stubborn and set in my ways, but I have already seen multiple projects try and fail to deliver something remotely reasonable due to the missteps above. I will need to develop a way to become more vocal about how decisions on technology choices should be made, and make sure that proper discussion and reasoning is the basis for the decisions; rather than hype and preference.