2.3 Popularity rarely matters

Generally, you should always pick popular technologies over unpopular ones. Better talent availability, more vibrant ecosystem and community support, vendor longevity, and more ready integration options will help you succeed. However, you should be aware of challenges and that popularity isn’t everything. It’s just one factor you should consider among others.

Popularity doesn’t mean the technology is automatically fit for your use case. For example, compared to monolithic architecture, microservices can add technical and management complexity that might not work in your environment. Popularity doesn’t mean the technology is necessarily cheap or there isn’t vendor lock-in either. Sometimes, the most popular solutions are the most generic, which means they might not address your specific needs.

A significant risk would be having only a handful of potential vendors and new talent not coming to the field. However, you should ask yourself how much popularity you need to ensure talent availability. If you can get professional services from 50 vendors, what extra value would it add if there were 100? 500? 1000? After a certain point, popularity may yield diminishing results. It also may not improve the viability of the chosen ecosystem.

The venerable TIOBE index tells us the most common global programming languages. You may allow only the use of the TOP-5 because of talent and service availability. You would also be misguided to do so. Lower on the list, you can find programming languages like PHP and Ruby. They can be extremely productive for web applications. Their 1 % market share still means millions of developers; you might have dozens of vendors available. They also have steady support from the ecosystems around them.

PHP with Laravel and Ruby on Rails might be top-tier picks for the startup scene. They are not the hottest new technologies but are productive and usually do the job. For many enterprise environments, they, however, may be seen as niche technologies. Please note that there’s nothing inherently wrong with being niche. Think of niche more regarding a nuanced potential, which can often surprise with unique benefits.

Niche technologies exist because they have specialized use cases. For example, Ruby on Rails has always been one of the most productive web development frameworks. It has always focused on creating the most fluent developer workflow in existence, and because of that, it has a group of technology users that will probably never switch.

Niche technologies can also be much more cost-effective. Lower popularity means less negotiating power to the vendors, lower or no licensing fees, and a better ability to impact the technology’s development. If you are one of the few users, you can ensure the capability to what new features get developed next. As a result, you get superior performance or unique features that your competitors will not have.

Sometimes, you can build a more homogenous IT environment by choosing the same technologies, even in cases where they are not the best fit. It is a risky move, but being more homogenous means the developers and maintainers will understand the technology stack of every system more deeply and will be able to optimize the overall environment. Most enterprise environments are virtually impossible to optimize due to their heterogeneity, leading to high overall run costs.

Basecamp and Hey publicly left the public cloud for an on-premises setup. The news caused a buzz in tech circles. Most of the commentators and articles missed the point. The public cloud is most cost-effective for most heterogeneous environments because the adaptability and the number of personal work hours required for changes plummet. For Basecamp and Hey, things looked different. They have a highly homogenous technology stack and an exceptionally able engineering team. Going against major trends to reap the benefits was a unique opportunity enabled by their technology stack, people, and processes.*

Of course, you will never want to use technology, which will be obsolete. Niche technologies also have a higher risk of falling into obsolescence if they fall out of favor. Be also aware that offering developers money will go only so far. Money doesn’t compensate for the effect that working with obsolete technologies can have on career opportunities in the future. Awareness of the risks of using outdated technologies is essential, as this awareness can guide your technology selection decisions.

Sometimes, technology startups build great new technology. They try to increase the number of users by giving out their technology for free. It has become extremely popular. Often, venture capital investors like the large user base and shell out investment money for several rounds. Then they come to that road fork where they must swim or sink. They often change licensing terms and add prices to previously free features. Monetization causes frequent forks, and the fledgling ecosystem of vendors and developers will partially collapse.

For example, Docker used to be offered using an open-source license, and most of the features were free. The company behind the Docker tried to monetize by changing the license terms and adding fees. Virtually overnight, most engineering teams switched to alternatives such as Podman and Kubernetes. While Docker containers may still be a de facto standard for most environments, virtually no one runs them with a Docker daemon anymore.

If you are unaware of the origins of the technologies you pick, and if single companies develop them in terms of their fiscal situation, you might face disruptions. Disruptions may happen with both the most popular and niche technologies just the same. Understanding the roots of the technologies you use is crucial, as this knowledge can help you navigate potential disruptions effectively.

There’s also this cynical view of software developers that there are two kinds. One is like a bureaucrat. He starts at 8:00 and stops working at 16:00. He doesn’t care deeply about technology or your business. He is just shoveling development tickets and bug reports mechanically. Sure, he does alright, but that’s about it. He will never attempt to learn anything new unless specifically instructed. He is there mainly for the salary and job safety.

Then you have the other kind of developer with deep knowledge and passion, the drive to learn more constantly, and a passion for software development. This kind of person doesn’t care about working hours (there’s an apparent work-life balance discussion here, but we will skip it!), challenges the bad ideas, argues for the good ideas, and always tries to improve everything. He is there because he loves solving problems and doesn’t care much about the rest.

Which technologies do these two developers use? The first uses the most popular ones because they ensure job safety. The second one uses whatever he pleases and is often passionate about many niche technologies. If you ask the second developer to use one of the popular technologies, he will. The difference is that he will be much more productive because he instinctively enhances the use of technology by bringing in functional patterns and concepts from other technologies.

But what happens when you build a niche team passionate about technology? You will likely retain that team for eternity if you manage it actively and assign the developers a constant stream of new problems to solve. Beware, however, that the day there are no unique challenges and opportunities for these developers, they will quit quickly.

You should also participate in tech communities, conferences, and open-source projects to build relationships with potential good candidates and as a thought leader. Not only do you get good talent acquisition opportunities, but that will be one of the tools for your continuous leading. While you might not be a software developer, it’s worth listening to them, especially in what kind of environments they want to work in, which may be a critical issue for your use cases.

As an architect, you should understand that the popularity of technology is one factor to consider. You should also evaluate how much popularity you need and consider the niche technologies. Evaluating the vendors behind technologies is also recommended, at least for your major technology decisions. Also, somebody has to work with the technology, and that’s often even more critical than the technology itself.