this vs that vs not
I see a lot of discussion on which technology or framework is the best. Too often, the conversation revolves around which on is the best on absolute terms. To make this less abstract, think about React vs Angular, or pretty much just any library, framework, or architecture we’ve had over the years. The idea that one thing is the best option for everything and everyone is of course plain ridiculous.
The opposite - yet still flawed - viewpoint is that of those who declare the chosen framework to be irrelevant. The only thing that matters, is the implementation and overall reasoning. Granted, the chosen technology matters little if the project fails on incompetence or mismanagement. The potential leverage provided by a technology can always end up wasted. There is a multitude of reasons why a framework fails to be the silver bullet, and why a DIY attitude might sound tempting.
But incompetence and the lack of know-how also applies to doing things on your own. If a person underperforms when utilising an existing framework, on what grounds would he do better when given even more options? In my experience, some constraints are good. The existing libraries provide conventions, constraints and rules for varying degrees, and if not abused, they are generally sensible. If they’re not satisfactory, you usually have the choice before the selection of the technology. You can choose the one with the most intuitive and fitting constraints.
Learning by doing is great if the given customer, employer or project constraints allow for it. Generally, they don’t. Frameworks need learning too, and in some cases that learning curve might actually be steeper than what a project allows. In that case, it’s usually better not to overshoot, and stick to what comes naturally.
a tool for a team #
By pure technological standards, the choice of technology might be obvious, but that alone is insufficient. We need to consider the people in implementing and designing team, as well the structure of work. As in who is responsible for what, and what kind of workflow are we dealing with. Also, there are the classic monetary, budgetary and timing constraints. The fact is, some technologies provide better grounds for faster development, while some are safer and steadier.
A large team or organisation might do better with microservices, modularity, and separation of concerns. They might benefit more from heavy constraints and rules, those found in static languages and strict scaffolding. A small team might excel with a single base behemoth advanced by prototype oriented development with a dynamic language. Projects and teams are rarely divided in any clear-cut categories, and it turns out you must figure these decisions out yourself.
In some of the worst adversarial arguments, the opposing sides tend not to acknowledge each others strengths, at all. Instead, they concentrate on weaknesses. For the reader, it is difficult to find out the fitting examples and real world use cases. Selection becomes overwhelming in a sea of biases and heated opinions. Projects like TodoMVC are a great start, but let’s face it, a todo app solves only a certain kind of a problem.
I’d like to think these tech1 vs tech2 debates are conducted tongue-in-cheek. But many are too serious. Some live in a bubble where the non-technological issues are irrelevant. For those who don’t have to think about business or people for that matter, they can concentrate on the minute technological details, and that is fine. Comparison and criticism are essential for advancement, and for the growth of the profession and our tools.
Technology choices matter, but they’re always only a part of the whole. Debates, comparison and opinions are good, but should not steer the technological selection process without consulting the human crew first.