Why Software Teams Adopt Technologies that Don't Make Them Productive
PotatoBeans Software Development Company
Kami mengembangkan sistem informasi kompleks untuk berbagai enterprise, untuk segala macam tipe penggunaan.
Whenever there is a new team formed, whether it's for a project, a new business unit, or even a new digital company, the team is always faced with an important question: what is the technology the team is going to adopt? This is by far the most important yet difficult question to answer. It is not really possible to find answers about this question directly, especially when a team is faced with so many options from programming languages, databases, storage options, even operating systems, and so on. In a web application project for example, the team will most likely begin with a question such as:
Following and criticizing all the questions above, you might end up with more than 30 questions. And this is only for web development. The number of questions unsurprisingly grow the more complex a project is. However, this article will give you some insight about how to tackle this very common problem, which might make your team more productive in the future.
The Basics
We need to first get the basics explained. The choice of technologies don't get chosen overnight. And the more complex a project is, the more complicated the decision making becomes. Fortunately, in reality, you do not need to use sophisticated decision making techniques to choose and answer those questions.
Uncertainty Grows the Lesser Experience the Team Has
The first step of answering these questions is to assess the overall experience the team has. This means gathering everything that everyone knows. Information technology is undoubtedly huge, and thus it is common for a new team to face new challenges with new choices of technology, something that the team members might not have seen before. You might be moving in to a new team, and by the time you move in, the technology you use is obsolete, and you will have to start anew with fresh choices, choices you have never heard before. This practically sets your experience back, and it is very common in information technology. Fortunately, most of the time, the experience you gained from previous technology could help you with newer ones.
When creating a new team, usually with new recruits, it is best to assess them by finding out what they know about anything. Some members might understand JavaScript, some other might understand PHP, or Go. Some other might know Rust, and some other might know Python. It is not that common to have a team full of people with completely similar experience, which is why the question about the technology of choice is a difficult question to answer. However, a team with very little experience will not get anything done. The incredible amount of uncertainties generated by a team with little experience will outweigh all of the effort trying to minimize them. You will face delays, complications, and communication issues along the way. This then goes without saying, it is generally a good idea to avoid building a team without experts.
It is important to note that the choice of technology in your team will most likely be the choice of the experts in the team, as they have the most experience. However, as the next section will explain, it is not always a good idea to ignore other team member votes and rely only on the most expert in the team.
Agile, But You Don't Get Second Chances that Often
Agile mindset has been created to deal with uncertainties in software development. However, the choice of technology is not something you can change all the time. The cost of fixing bad choices might be too high, and sometimes you will have to stick with it, even with Agile.
Especially when it comes to choices concerning foundational components, such as programming languages and architecture, they are intertwined with the mindsets of the team members that use them. People that are detailed like to work with Java. People that previously dealt with many data analytics probably prefer to work with Python or Ruby or R. Changing technology such as languages sometimes obligates the change of mindsets, something that is quite difficult. Although most of the time people do not simply change programming languages in the course of a project, people do change other components such as frameworks/databases to use.
Suppose that you have a Java expert in the team. Being an expert, the member has a lot of voting power in the team, and has proposed that the team sticks with Java for the rest of the project. Java is notoriously verbose to write, and can be difficult for new comers. This means the team is left with little choices when hiring new members.
Being an expert in software engineering is different with being an expert in a particular language. Being an expert in software engineering relies understanding of the software engineering mindsets, such as algorithms and logic. This means despite being an expert in a particular language, provided that he/she is also an expert in software engineering, the expert is actually the most flexible. Being an expert in software engineering allows you to learn languages quickly, and even write better codes in any other languages than the one you are currently using, compared to people with less expertise.
Due to the fact that sometimes switching technologies is not an option, it is better to consider the future implications of one choice regarding the member dynamic of the team. In other words, assume that in the future you can expect that some members of the team will leave and be replaced. How easy it is for them to be onboard?
You, as an HR department, might be inclined to just "find people with the right fit". If only information technology were that simple. How "fit" is someone to you? If the team has been using Java language, you might be inclined to hire Java software engineers, and you could be right. You might be inclined to also add another requirement in which new hires must also know Spring, a framework in Java. You keep adding requirements until you find yourself having no applications.
There is an obvious trade-off between specificity of your requirements and the length of the hiring process. So the more requirements you impose, the harder it is to find a match. Many people instead stuck with opening a job application with very strict requirements that it is very difficult or expensive to find a match. Not to mention the chicken-and-egg problem that many companies created due to setting experience years bar too high, which will eventually backfire.
In summary, as you do not get that many chances to recover from bad choices that often, you might fall into the trap of wanting to hire people with the perfect fit, something that might be impossible to do.
It is in the Mindset
People usually measure expertise with how well people do something in a particular technology, and they are probably right. However, in the fast-moving era where new technologies come up almost all the time, this measurement might no longer be relevant. Looking in the market, people also tend to forget about the foundations of software engineering.
From Wikipedia, the American Engineers' Council for Professional Development (ECPD, the predecessor of ABET) has defined "engineering" as:
The creative application of scientific principles to design or develop structures, machines, apparatus, or manufacturing processes, or works utilizing them singly or in combination; or to construct or operate the same with full cognizance of their design; or to forecast their behavior under specific operating conditions; all as respects an intended function, economics of operation and safety to life and property.
There are many key points here. First is creativity. The definition above is about engineering in general, and software engineering is no exception. Turns out all engineering fields require creativity. It is a principal component in engineering. Expertise in software engineering thus can be defined by how creative an individual is when trying to solve software-related problems.
The other terms are design, develop, construct, and operate. All these talk about how engineering does not relate only to construction or development, or operation, but also design. Design requires analysis, and analysis in turn requires creativity. Therefore, the ability to design a working code is part of software engineering, and it requires creativity. Expertise in software engineering can then be seen as how well a person can design a solution, not only about how a person develops/constructs their solution.
Through this section it should be getting clearer that whatever your technology of choice is, it comes back to the foundational knowledge of the team. A team consisting of 5 years experienced Java coders is not necessarily an expert team. The expertise is in how well the team can come up with a solution to problems the team is facing. And as it turns out, the more expert the team is, the more flexible you are with your choices, and the less severe the consequences are when you turn out adopting the wrong technology of choice.
People with strong foundation in software engineering always have a good sense of code smell, good creativity, and good proficiency in code writing and algorithm design. They do not stress much with what languages they are writing, or what databases they are using, or what API they are calling. It is not that those choices become unimportant, it is just that you are open to more easy choices, and thus uncertainty drops significantly, lowering the risk of issues in the future.
Many people however, think like simple coders. They fuss about what languages they use. They believe that the more proficient they are at writing a particular language, the better they are. While this might be true, software engineering requires much more than that, and it is common for people to get stuck without any kinds of real growth in creativity or logic when they believe they have already achieved a certain level of proficiency mastering some programming languages or technologies.
Technologies Change, But They don't Change that Fast
It's true that technologies change and new ones replace the old ones, but this don't happen that fast, at least that fast that is disruptive to you. Even after 10 years, your codes won't likely to break that easily if you follow the best practices, and your system won't break if you chose to use stable components.
This means, whatever technologies that you choose, you can be sure that as long as you are using them correctly, they won't betray you in the future, or at least during the course of the project. After all, software development happens incrementally. Designing a system that is not open for extension or upgrades is surely the same as designing a system that is bound to fail. Therefore, even with old technologies you can always incrementally upgrade it, which will cost even less.
Old technology may cost you less than newer ones as older ones could be simpler, readily available, and more stable. Newer is not always better, and certainly not always more fitting. Newer technologies are always around the block, such as distributed databases, distributed storage, programming languages with new paradigms, and so on. These new kids do not always contribute in adding value to the team.
As previously stated, it always goes back to the foundation. The foundation of the team is built upon the foundational knowledge of each member, i.e. the expertise of each member in designing a solution. This means having creativity in not only using the technologies but also designing solutions around the technology. With this being said, you should always look for people that are expert in SQL and relational database administration, not people that are expert in PostgreSQL, a type of relational database.
Even if you do go with PostgreSQL, a type of relational database that has been around since even the 20th century, the mindset stays. PostgreSQL, MySQL, and MariaDB are some of the most stable relational databases in history. The concept of relational database is tabular format, which is pretty easy to understand. They do not fit in all use cases, but they sure do fit in the majority of use cases.
Over time new relational databases come up. They are built upon databases that have already existed, like CockroachDB is built with PostgreSQL SQL language support. But the newer kids do have their own problems that do not exist in older solutions like PostgreSQL or MySQL.
Technical vs Business Aspects
Some technologies provide not only technical benefits but also business benefits. These benefits are most of the time promoted in their promotional websites, such as providing less down time (more stability so you do not lose revenue), more features so you can do this and that without having to deploy other supplementary components, ease of use so you can fire half of your team, and so on. It is important to assess the state of the team first before considering them.
The main point of making a decision is the ability to reduce the dimensionality of your options. You do not want to consider too many options with too many factors. Most of the time, if you happen to be facing this question of which technology you need to choose, you and your team are in the initialization state. During this state, many other things are still undetermined. You have yet to assess the business value your team can bring to your company.
Therefore, when asked with what technologies you are going to use, it is best to omit business aspects for a while. Many of those technologies do offer real business benefit, but you might not be able to feel them. They require a lot of integration with other components for the benefit to come true.
This is the same as playing one of the hardest sport in the world: golf. When playing golf, players like to choose and replace their clubs. The choice of clubs is as difficult as the choice of technology described in this article. People tend to devote a lot of time and energy in choosing clubs and their choices are usually very personal.
Many clubs offer a lot of benefits to the players, such as forgiveness (ease-of-use), distance (performance), and even looks and feel. However, for new players, most of these benefit usually mean nothing. Their inconsistencies in playing will far outweigh the benefits. This puts a lot of weight in practice, as through practice players can get more accustomed to the clubs they are using and start to shoot better. Many new players look for advice in forums and get disappointed where people just tell them to practice first and find what is good for them. A 9 degree driver (a type of golf club) and a 10.5 degree driver won't be that much of a difference in the hand of a new player.
Same as MySQL and PostgreSQL won't be much of a difference in the hand of a new team. Let alone PostgreSQL and CockroachDB. You will most likely feel improvements if you are able to implement your solutions well and consistently, by all team members, using just simple technologies that most of the members already know. With a fresh team, you won't even feel the technical benefit offered by the technologies you choose right away, let alone business benefit that can bring benefit to the company. With an experienced team you will most likely feel technical benefit of your choice right away, but not business benefit.
There is, however, some factors that newcomers should still consider when choosing a new set of clubs: ease-of-use. Some clubs are notoriously difficult to use, as they are designed for advanced swing styles that can alter the golf ball trajectory. It is better to stick with the ones that are easy to use, as this means practice can be more effective, and so consistency can improve quickly. This overall will translate to quicker time to buy more advanced clubs in the future.
It is exactly the same with technology. Simple and stable technologies help development to move forward effectively. This allows every member in the team to effectively grasp the basic goal, design, and architecture of the system they are developing, independent of technology of choice. This allows you to move forward to better technology in the future with less pain.
Moreover, it is commonly said that you will need to consider these technical things when choosing a technology:
Integration becomes an important aspect to consider as it directly relates with ease of use. When your technology can integrate nicely with existing ones, your development becomes easier and you can think about it as an important factor to consider.
Security although important is a very difficult thing to consider. It is difficult to agree on a security benefit of one choice as people do not usually feel it right away. It is best to consider choices that offer good enough security instead of having too much thoughts in this.
Performance benefits, like security, cannot be felt directly. Most of the time performance aspects need to be considered only when building a high-performance system that is confirmed to have a high numbers of users or do a lot of heavy tasks.
Budget is also an important things to consider. Budget can be thought as a constraint in your choices, so make sure your choice will always fit the budget. Keep in mind that not all technologies that are free are bad. Sometimes free things can also be good. Open source technologies are usually widely used that there are a lot of documentations and forums talking about them, and the most important thing is that they are free. You can also consider these.
Scalability means how easy your technology scale over time when things become more complex. Almost all technologies market themselves as a scalable solution. However, although some technologies are more difficult to scale then the rest, scalability mostly relies on how you use them, and your solution general design and architecture, not the technology itself. Like performance, it is very difficult to forecast and feel scalability aspect of one technology. Therefore, it is better to put scalability aspect a lower priority when choosing a technology. After all, newer technologies are almost always designed with scalability in mind.
The Components of Choice
When dealing with information technology, whether you are starting a project or even a business, there is usually a few components that you typically have to choose. The list of components might be unlimited depending on your goal, but these components almost always exist in every software development.
The Programming Language
This is the obvious part. All information technologies always involve programming languages at some (or most) part. The choice of programming language to use is sometimes permanent, so you might want to give extra attention to this.
The choice depends on what kind of products you are going to make. Web applications tend to use JavaScript, while mobile applications can use Java or Kotlin (for Android), or Swift (for iOS), or even JavaScript (again) and Dart for hybrid applications. Data-related tasks can be supported by Python or R. Embedded systems are usually written with C or Rust.
Programming languages can be strict or dynamic. Strict languages are languages that demand strict typing where you have to define variable types, function return types, and so on. C, Go, Rust, Dart, Java, Kotlin, and many others, are example of this. Dynamic languages do not require you to be strict with whatever you write, and so tend to be shorter. Usually, with a team of experienced engineers, the choice eventually boils down to choosing strict or dynamic languages.
When learning a new language is not costly, you can make decision based on programming language style first, and then the programming language. But when the team experience is limited, you will have to look at what most of the team members can do. What is more important is understanding the common use cases of each programming language that you are going to choose from.
The Database
It is almost certain that whatever product you are going to make, you will be storing data and processing them. Database therefore becomes crucial, and like programming language, the choice of database is sometimes (almost) permanent. However, migrating to other databases could be easier than migrating to other programming languages, so the consequences of bad choice will not be as severe as the choice of programming languages.
The most famous database in the world is RDBMS, or relational databases. MariaDB, MySQL, and PostgreSQL are all relational database. Other databases that do not follow the same principles like RDBMS are usually called NoSQL, as you almost always use SQL to interact with RDBMS. Some examples of famous NoSQL are MongoDB, Apache Cassandra, and Redis.
It is important to understand the distinction between their architecture or core working principles. MariaDB, MySQL, and PostgreSQL are all similar, and they completely support the SQL standard with some additional features unique to each of them. Redis is an in-memory key-value store, commonly use as a fast temporary data cache. MongoDB is designed to be a persistent storage like RDBMS but without the use of SQL. Neo4J is a graph database designed to store data in graph-like structure. Apache Solr and Elasticsearch are also databases which are designed to index a large body of texts from large documents and records for easier text searching.
领英推荐
The Supporting Development Tools
Development tools are as important as programming languages themselves, and the choices are sometimes even more permanent than the choice of programming language. For example, if you have used a task-tracking software and have created a lot of tasks for your team over the course of the project, it is not really practical to migrate to other task-tracking software as data need to be exported and re-imported again. Migrating to other development tools can cause long-term team-wide headache, something that must be done only when absolutely necessary.
Due to the importance of development tool choices, it can sometimes be prioritized first. People usually store codes in Github, Gitlab, or Bitbucket. All of them have similar features like Git repository, issue (task) tracking, and code reviews. Eventually choosing them can become a matter of preference.
Many open source projects are hosted in Github. However, many of the Gnome (https://gnome.org) open source projects are hosted in Gitlab. There is usually not many technical benefit of choosing one over another, so this may be left to each of the team member preferences, which simple voting can solve.
Just remember that whatever choice you made, it is usually even more permanent than the choice of programming language. Typically, in a development team, the choice of development tools boils down to these components:
The Infrastructure
Infrastructure here refers to the servers you are going to deploy your systems to. Even when developing a completely offline applications, you will most likely need a server that can run 24/7, to support your development tools or other stuff such as building and testing your codes.
Most people rely on cloud as they can get it going quickly. While cloud can be costly, they can also save a lot of time and hassle as they are designed to be stable.
The choice of cloud is typically a matter of budget. Most public clouds usually offer similar features, especially when it comes to basic features such as virtual servers (also called VPS, VM, elastic compute, and so on).
Other than the supporting hardware, software infrastructural components such as Kubernetes and Docker also become a choice when it comes to bigger projects. Simpler projects tend to be simpler to manage and do not typically need complex component such as Kubernetes.
The Recommendations
Now that we have mentioned the issues of choosing technologies, we should now talk about a few things that you might be able to follow to help you choose better.
Rely on Foundational Knowledge
It is very common for a company to hire new developers for a new team when they are trying to develop on a new product. Most HR staffs don't really care about technical details when they try to create job specifications. They just copy and paste what everyone is doing, without trying to integrate company-specific values to the job specification to help find people with better fit. There are few notes about this:
Foundational knowledge is very difficult to test. Just like scientists have been looking for what is called "general intelligence" for years, we too have been looking about what are the factors that make up a good technology engineer. Especially when it comes to foundational knowledge, such as code cleanliness, logic, and creativity in writing codes, they become an important asset in the team. Most of the time, these intelligence don't come up right away. The team job is to teach new members about these as well.
Code review is a good way to share foundational knowledge. You may never be able to teach someone to be creative. But you may be able to show them how. People do learn from mistakes, and code reviews help them learn faster. It is a shame that many teams do not even have code reviews.
Let's now assume that you have successfully gathered people with good foundational knowledge. The choice of technology becomes an easy task as you now can rely on choosing based on foundational knowledge instead. It's like choosing relational database vs NoSQL, or strict vs dynamic language. This choice becomes important, as most of the time the technology you will use will grow, while the foundational factors stay the same. Even in a team with various experts, you should still rely on these foundational choices, and not specific technology. Remember that in this context, you are starting anew, so you have not gotten the foundation laid up. Most people don't even have any foundation and do not have any basic reasons of choosing one technology over another.
Say you now have people experienced in C and Java. Your team is tasked to develop a new web application complete with new web services and frotnend. The choice of programming language now lean towards the choice of strict languages as C and Java are strict languages. Do not force them to learn new languages with completely different mindsets. You can then choose Go, or at least PHP, with TypeScript for the frontend. In PotatoBeans, we even use Dart with in-house built frontend framework to leverage the strictness of Dart.
The Technical Benefits of One Choice is Usually Trivial
You can say that you want to stay away from using Python as Python is generally considered slow, and you might be right. However, in the context of a new team, the disadvantage is usually trivial. You might be inclined to use Go instead which is considered faster than Python.
The benefit of Go being faster than Python is usually trivial in a new team. Most of the time you won't be able to feel it anyway. If you rely on choosing Go because it's a fast language then you will have to have a perfect reason as to why you need this performance benefit in the first place. If you already have a team that are expert in dynamic languages, it is not productive to force them to use Go, which is a strict language. You will get more benefit sticking to Python instead as most likely your team will be able to write good Python codes that can even be faster than bad Go codes.
So when starting a new, or even adopting new technologies in the future, do not solely rely on the technical benefits they offer. Instead, prioritize the goodness of fit of the technology with your team. This means considering ease-of-use and common use cases of the technology. The R language is mostly used for statistics, don't use it for web development as although it can it might be more difficult to do it with R.
Also, avoid choosing a technology just because everyone is using it. Avoid choosing a technology just because everyone is advocating its benefit. Most of the time, you won't feel the benefit, or the benefit might not even apply to you.
Why were lots of technologies that become open source came from a lot of companies? That's because big companies tend to already have a good sense of what is fitting to them, they they have to create their own technologies that fit them. After these technologies get mature, they release them as open source. I won't talk about the reasons as to why they are released as open source, but how the most important thing here is how they prioritize fit and suitability for themselves over other things and do not really care about what other people are using.
Prioritize Stability over Other Things
Whatever you choose, make sure they are stable. This means the components don't break that often, and are well-documented and supported by a lot of communities on the internet. It is perfectly fine to choose older technologies if they fit the current needs and is very stable.
How do you know something is well-supported? By the number of documentations existing on the internet. If there are a lot of people talking about it, if the number of GitHub stars is high, and if there are a lot of people complaining about it. This means you will be able to debug things faster, which is crucial. Software development is by nature uncertain, do not make it more uncertain by choosing things that are not stable.
Consider Flexibility of your Choice
Flexibility often time result in ease-of-use. Technologies that are stable usually are flexible. Let's talk about the case in programming languages.
It is most likely you will need a lot of dependencies in your project. Dependencies are extra packages (or libraries) that help you implement things. In JavaScript, there are a lot of packages that can help you do things, such as creating a chart in your web application, developing a 3D model, doing analytics, and so on. JavaScript is a considerably mature language with a lot of support. Go on the other hand, might not have that many support. If you do not have any preferences of using a strict language in the first place, you can stick with JavaScript to allow yourself more room for flexibility.
If you like to be technical, and are trying to write a web service, I urge you to consider 12-factor apps (https://12factor.net/). It's a set of concepts that you should follow in order to develop a 12-factor apps. One of them is the use of containerization to containerize your applications/services. This means using Docker container or something else to turn your application into a containerized application that is easy to deploy.
Because of this, sometimes Docker no longer becomes a choice but an obligation. There are other containerization technologies out there, but Docker is one of the first and also one of the most famous and easy to use. Podman is also a good replacement for Docker that offer similar features with more weight on security. With containers, you will more flexibility in deployment. It is easier to deploy containerized applications compared to simple applications with a lot of files and components. It is generally a good idea to invest in these technologies that ease your life in the future instead of relying on all-simple and bare-bone technologies just to get things going quickly.
Keep it Simple Stupid (KISS)
Simplicity oven leads to stability. Simple things are easier to understand, easier to manage, easier to setup, easier to debug. If simple RDBMS like PostgreSQL works, why choose other things that might be more difficult?
There are many other derivatives of RDBMS with advanced features. You can choose to start with them, or you can choose to start with famous RDBMS like PostgreSQL and MariaDB. Most of the time you won't need the advanced features right away, and the added complexity will only set you back.
Unless you do have reasons or experience with advanced components, it is better to stay away from them and just use simpler ones. These technologies are famous for a reason, and although they do have their own disadvantages, you might be able to work around it in the future anyway.
There are some reasons that you may want to consider when using advanced technologies. You might be interested in high-availability, something that might be difficult with PostgreSQL. Or you have high confidence in your prediction that your system will have a lot of users and so require high-performance database or other technologies. All these factors do contribute to your decision-making process, although it is not usually common to start a project with such advanced feature requirements right away.
Agile exists due to the fact that we usually make bad predictions. What we predict in the future might be wrong, and sometimes there is no way to confirm it. We sometimes have to live with it and deal with that mistakes. Therefore, it is best not to make assumptions first that rely on the use of advanced technologies right away. Most companies start with simpler technologies and grow up from there, migrating each component one by one when needed.
Consider Technologies that Help Teamwork
This is especially true when choosing development tools. Don't choose things that are difficult to use, as this will be difficult for everyone. You can first try them out to see if they are good for your team.
Tools that easy to use will not be a threat to your overall teamwork. Remember that in a team, integration and communications become crucial. Do not use tools that will hinder your communication. This includes the choice of communication platform.
Say that your team consists of older men that do not know Discord. Discord is famous in the gaming community, and has a lot of features. However, many of your team members have used WhatsApp extensively, and feel that Discord can be more difficult to use. If you keep on using Discord, troubles might come along the way where they make it difficult to communicate with each other, which will certainly hurt productivity. This example is far-fetched, as most people in the technology field usually have no problem in learning new things, but it tells you how wrong choice can make communications harder.
People also do not like to document their codes, or whatever they are doing when they work in some non-coding problems. If you feel that you like to enforce strict code design that might be easy to explain and read, you can consider strict programming languages, as they enforce strict design. No matter what you choose, consider the communication aspects of your technology.
I also recommend adding wiki and documentation platform in your choice. Other than considering what languages, databases, or storage management to use, also consider how you will be able to document your actions. Golang has Godoc, Python has Sphinx. If documentation for a certain component becomes a difficult thing to do, I recommend to stay away from them. You will eventually be grateful with documentations, as it helps your team work more accurately, reducing uncertainty and risk of failures.
Codes don't always self-document themselves. Documentations and tests are as important as the codes themselves. Therefore, it is better to have documentation ready in place, in-code, or out-of-code. Gitlab and Github do have wiki features, and you can also deploy wiki sites for yourself like wiki.js or readthedocs. I believe it's a good thing to invest your time in considering these options.
Rank your Options
Most people just choose options based on their gut feelings, without any set of methodologies that are reliable. While this works most of the time, it is more accurate to first consider all your options and rank them using simple methods instead of using no method at all.
Especially in the case of a large team, you will most likely have a lot of members. Each of them has a saying over each of the option. You can rank them based on basic SWOT, where you consider the Strength and Weakness of each option, and try to find the Opportunity and Threat you might find along the way of choosing one option. You can later try to vote and give a score on each of the point and sum the score before making a choice.
There is a benefit of using a methodology like this: it is documented. You have a list of factors/aspects that you consider and they are well-documented. You can later bring up these list of factors in the case you are going to adopt newer technologies in the future, onboard a new team member, and so on.
Your Choice is Unique to You
Sure there are good and bad technologies out there, but they all depend on your requirements. Therefore, the solutions that you come up with are unique to you. There is no reason to compare yourself with other people.
Don't be like some people that like to brag about one technology over another. A few years back when NoSQL was viral, people talk about it as a way to hate simple SQL databases. Although NoSQL databases were not always marketed as a "no SQL solution", people tend to understand it that way, perhaps due to the jargon "NoSQL". They consider NoSQL as an easier alternative to SQL, due to SQL being difficult. Today, RDBMS has proven to be more common than ever. At the end of the day, what works will never lie. Just like the common saying: don't replace what has already worked. It has been more stable than ever, and has proven to be a good solutions to many use cases, even some of the most advanced ones.
There is no use in getting peer-pressured either. What works for others might not work for you. As explained before, whatever you choose will bring benefit only to you, and some of these benefits can be non-performance related that are unique. Some examples:
The above reasons are really not performance related and more preference related. At the end of the day, it is perfectly fine to choose things based on preferences and what you like, instead of what those technologies do or offer to you. You tend to work better with things you like, regardless what benefits they bring to you in the end.
Afterword
At the end of the day, the choice of technology boils down to the choice of what you and your team like about them. These are unique to you and your team, and you will have to stick with it as changing them can be a costly action. The choice of technology should be based on values they offer to your team, and this will become the foundation of the culture of the team.
What is more important than the tool is the user. It's not the plane, it's the pilot. How you use things is eventually what makes your choice crucial. There is no benefit in choosing technologies that you or your team cannot use.
There are some large companies that still rely on PostgreSQL or even Java to run 90% of their systems, serving billions of users. Many databases have been marketed to offer advanced features compared to PostgreSQL or other common RDBMS. Java, although considered old and verbose, can be very powerful in the hands of people that are expert in it.
I also want to emphasis the importance of keeping your options open. Technologies are changing, and there is no use of being so stubborn in one choice because you are already good at it. Sometimes the new kids do offer more benefits, and it is good to consider them. When a choice no longer serves your purpose, it is perfectly fine to migrate to new options. Maybe the programming language that you use becomes obsolete and difficult to use, it is good to invest your time to migrate to new languages that can help you stay relevant in the market. However this choice remains a choice in the future, not something you can consider immediately when starting a new project.
Whatever you choose, stick with it and make sure you have a good grip on it. In time, usually you will learn to avoid the pitfalls with anything that you use, and will actually bring benefits. Remember that you are trying to fight uncertainties in your team, not introduce more.