Discussions about “the best programming language or technology” are common in software development, but also arguably pointless. Choosing a programming language is very unlike construction work: you don’t need the “right tool for the job”. It is more like choosing clothes to wear: you shouldn’t pick shorts when it’s freezing, but all sensible choices are a matter of taste and maybe even a way of expressing your identity as a developer.
Software engineering is a profession that requires a great deal of creativity, and creativity is boosted by constraints. Technology choices are such constraints, but nevertheless constraining technology choice is considered controversial in our industry. Why is that?
Popular software development stacks for web products
Let’s consider the following popular web development stacks:
- Java with SpringMVC
- PHP with Symfony
- Ruby on Rails
- Python with Django
- NodeJs with Express
- Go with Gin
- C# with ASP.NET MVC
These stacks are much alike. You can build the same web-based software applications in them. They all provide the same pattern: separating data access, business logic and presentation in layers. They all have modules or objects to chunk the code into same sized units. They provide the same components: a router, a cache, a Data Access Layer and a template engine. We can safely say that design of software products is a solved problem with lots of well-know best practices (implemented in these stacks). Therefore it would be beneficial when non-technical arguments would prevail when choosing a stack.
Three things to base a technology choice on
The three things I feel you should consider when choosing a technology are:
- Ease of learning of the technology
- Popularity and age of the technology
- Openness of the technology
When technology is easy to learn, then costs of learning are low and it is more likely that people already know the technology. Popularity and age are important for the same reason and also because older and more popular technology is less likely to have major flaws. The last one is a different beast. The best example of it is “Flash/Flex”. Apple would have probably not even been able to kill it if it would have been an open standard implemented in many browsers.
A full list of considerations for technology choice
These three points can lead to the following list of considerations:
- What the other people in the company are doing (building expertise)
- Ease of finding developers (hiring is expensive and common)
- Technology your employees are familiar with (to avoid long training periods)
- Access to other companies using that technology (to learn from each other)
- Learning curve and availability of documentation (in case people have to learn)
- Availability of tools to debug and analyze performance (for solving issues)
- Amount of alternatives for the technology (to easily switch components)
- License that the technology is using (it should be free and open source)
- Availability of commercial support (the option for commercial support is great)
If you decide on these factors then you easily see that this is not a typically job for an engineer. This is a strategic decision that should be made (and enforced) at C-level (preferably by the CTO). Unfortunately not many companies I know of have the guts to take that point of view. In the product software industry the technology gap between the board and the engineers is so big that the strategic value of these choices is often overlooked.
Technology should be dictated by the CTO
Arguments you may encounter against this (and there replies) are:
- Developers wouldn’t want to work with old/boring technology,
- … but seniors would and juniors want to learn.
- Constraints hurt the creative process of software development,
- … but creativity loves constraints.
- Senior developers wouldn’t be challenged/learning enough,
- … but how about soft skills/mentoring?
- Development wouldn’t be innovative,
- … but whatever you innovate would have more impact.
- Our best engineer says that technology X will bring us the moon.
For that last one I blame conferences, where cargo-cult developers hear stories from companies they would love to work for. They want to believe the technology is amazing and blindly believe all promises made, because they idolize their hero’s for creating it. These engineers can easily convince their managers as they are promising them the moon.
If you don’t understand it, then it probably ain’t true.
So it all boils down to a lack of self confidence (both the engineer and their managers). So let’s stop the madness, invest in understanding technology and live by the anti-cargo-cult slogan: If you don’t understand it, then it probably ain’t true.
Enjoy coding!