A developer and project manager from our team X says the following about our use of Rails at i22:
"We use Rails to build stable and flexible backend systems. Rails is extremely good for managing data structures and quickly setting up new systems. It is the perfect base for most use cases."
I asked the same Team X member why the team prefers to work with Ruby on Rails, rather than Python and Django:
"Because Python is a scripting language and from my point of view not suitable for building stable web services. Python is for me rather good for scripts and fast small tools. Not for stable business applications. And if I want it fast I prefer Go."
I totally disagree with that.
Besides the X vs Y opinion based comparison, businesses should focus more on some technical analysis and Just In Time software design and architecture.
Of course all the decisions should take in consideration technical expertises available in the development team, because team retrain times and costs should be evaluated and compared to the benefits of a new technology adoption.
If performance is a concern, investing on some R&D to develop some barebone PoC "apples to apples" comparison should be considered.
This can help to mitigate technology adoption, and also retainment, risks and avoid the much bigger risk of opinion-based decision making (which, as a personal opinion made on available information in this case, is based on outdated knowledge and apples to oranges comparison - like comparing batteries included fullstack frameworks vs bare languages).
Even if all of these layers of analisys confirm an initial opinion all the insight generated will help the overall design and management of the product/project producing extended benefits during development.
Hi Matteo,
thank you for your input. I would like to respond "very briefly" to your feedback :)
Technology decisions are neither dogmatic nor necessarily dichotomous at our company. Accordingly, your criticism is rather due to the orientation and mode of this platform, which calls for the A vs. B scheme.
We have a clear attitude towards technology decision making. At i22, the choice of technology belongs in the hands of the project teams. They decide - and no one else.
But we go even further. Teams work with us on their own entrepreneurial responsibility. They manage not only tech decisions, but also their resources, customer relationships and projects themselves. Because here, too, hierarchy would only slow down the process.
Who can decide faster and better which skills are needed and how priorities should be set, if not the experts in the project in close proximity to the customer?
Our customers deserve individual solutions for their needs. We don't just reach into the shelf and take care of every customer problem with a standard solution. Every tech stack is tailored - and to do that, we have to be flexible, technically adept, and fast in our decision-making.
tl;dr if we had a case where Python is the most effective and efficient tool for a solution from all perspectives, we develop with it. We do not decide dogmatically against Python, but in the use cases from the concrete team X.
Thanks Mark,
Your explanation gives a really Agile and smart vision of your company, differently of what was my first impression (which had no context of the project).
Team and project are the most weightful voices in choice for a product architecture. I find that nowadays become more and more difficult to choose between same tier technologies/languages/frameworks, mostly because they have very similar level of features offered and developers experience. There is hardly an overall better solution for all the cases. If everything has to be diceded upfront risk is really high and that was my warning.
Good luck with your project!