Decision making in tech
Vaibhav Rathore
December 14, 2017

Many times, while working on various tasks, you must’ve got stuck between options and cannot decide which one you should do. The easiest and most obvious route is you do the research and probably take consultation if needed. Many people manage a list of pros and cons and based on which column has more pointers, they go with that suitable option. Everybody has their own method in the times of decision making.

Decision making: today

A similar thing happened to me today. While working on a new feature that enables us to send emails from Amazon SES. I had to decide to either go with an existing functionality and quickly set up the feature or create our own from scratch. Like everyone, I started with the research, installed the existing plugin and played with it. I realized that we may face some compatibility problems as the existing plugin doesn’t come with all the feature support that we need in our workflow. Later, I was convinced that instead of making tweaks and writing code over the plugin, it’s better to create our own. Of course, it’ll take some more time, some more effort and may be confined to our workflow only, but it’ll support our system 100%.

Maybe in later, if we find some time, we can generalize our custom plugin and release it to the public so that teams having a workflow similar to us may find it useful. That was one.

Decision making: past

While writing, I recalled another situation with one of our clients. If money is involved, every minute becomes crucial. For a specific feature request, we were uncertain of the functionality and needed some research. We asked our client for a specific timeframe where we’ll (hopefully) figure out an efficient and compatible solution. During research, I came to a similar situation of decision making. A paid plugin, way too high on cost as compared to plugins that I daily encounter. Should I go with it or create our own? What if the paid version doesn’t support a specific ability that we want? Is it compatible with our source code? What if plugin authors decide to not work on it anymore and it dies? Will our plugin enable more control? Which route will be cost-effective for our client? There were many abstractions.

We proposed two plans to our client. First, let’s go with the plugin. Second, let’s build our own. We clearly mentioned the pros and cons of each. The paid plugin had many abstractions. We proposed that we can communicate with plugins authors, ask for a full demo or inquire about the features that we want. This will take more time and have chances that if there’s any feature not supported, we’ll have to kill it from the requirements. We also mentioned that all required features can be built into our custom plugin. The control will be supreme with no compatibility issues. But the cost would be higher than the existing plugin. Finally, at the end, we mentioned which option we prefer is best. The client saw the pros and cons, analyzed and finally agreed that it’s best to go with the option that we also prefer.