I get this question a lot from our customers when we recommend technologies as part of the new software development proposal. Why not MySQL instead of Postgres? Why not Kotlin instead of Java? Why not Vue.js instead of React? Why not Memcache instead of Redis? Why not Dropwizard instead of Spring Boot? Why not Flutter instead of React Native? And the list goes on. The important point to note is that the alternative is not radically different from the proposed technology. Both options more or less have the same characteristics. There are successful products built using both the technologies. In this post I want to discuss how to answer why not X questions.
In this post I am not covering situations when X is very different from proposed technology. For example, why not Cassandra instead of Postgres? Or why not Aerospike instead of Redis? Or why not Rust instead of Java?
The obvious answer to why we propose certain technologies is that we have expertise in them and it is easier to find engineers in the market for those skills. But, when people ask this question they want to hear strong technical reasons not the usual boring obvious answer. So, the obvious answer does not fly.
So, how should we answer this question?
The best way to answer this question is to start by understanding why they are suggesting X technology. You can understand that by asking them about their:
- Production experience with X
- In-house expertise on X
- Current technology landscape
- Satisfaction with X
If we understand that the customer is already using technology X successfully in their organisation then it is better to go with X. There is no point introducing a new similar alternative technology. Depending on the technology you might still have to train people so please add the training cost and time to the project. So, discuss it with the customer and take their buy in. Most of the time this is what the customer wants. They want you to agree on X.
Next, it could happen that the customer does not have real experience with X but they think it is superior to the suggested technology. Now, you have to help them understand that your suggested technology is similar to their technology. For example, Java has added many new features since Java 8 to improve the language ergonomics. This means the difference between Java and Kotlin has narrowed down considerably in the last 5 years. It could happen that the customer is not aware of the new features and six monthly release cycles. Comparing the two technologies at this level can help them understand the similarity between two technologies. This requires you to have some experience and opinion on both the options. It is always helpful to build awareness and opinion on similar technologies so keep learning and exploring. It will help you sail such meetings and discussions. If you know nothing or lack enough knowledge about X technology it is always better to ask for a future meeting slot to discuss it rather than saying something incorrect or playing down X technology.
Finally, it could also happen that the customer also has no clue on technology X but they are asking for the sake of asking (it also happens). Then, the best way is to help them understand why you proposed certain technology rather than explaining why you didn’t go with X. This usually involves talking about features of proposed technology that help meet requirements better. For example, when talking about Postgres discuss its JSON support, extensions ecosystem, cloud managed services, parallel queries, etc to help them understand why Postgres is the right choice.
Shekhar Gulati 