TQ
dev.com
Blog about software development
24 Oct 2017 - by 'Maurits van der Schee'
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?
Let's consider the following popular web development stacks:
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). Therefor it would be beneficial when non-technical arguments would prevail when choosing a stack.
The three things I feel you should consider when choosing a technology are:
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.
These three points can lead to the following list of considerations:
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.
Arguments you may encounter against this (and there replies) are:
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.
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!
PS: Liked this article? Please share it on Facebook, Twitter or LinkedIn.
Subscribe