Startups, Tech and Vietnam

A guide for making the right technology choice

Now more than ever, engineers have lots of choices in their toolset to build amazing products. Those choices are sometimes key to the foundation of the product. How can you make the right technological choice? I have been making technology decisions for the past 10 years. Sometimes those decisions were driven by hunches. With time though, I have refined a process to make important decisions less random or arbitrary.

If you are faced with confusion or uncertainty about an important technological choice, I hope this guide will help you.

In this post, I will take you through my 4 step process to making technology choices. I will refer to high tech examples (e.g: how to choose a programming language) as well as a low tech example (how I chose my day-to-day mode of transportation in Ho Chi Minh City). I chose a low tech example so that non technical readers can understand the process.

1. List your requirements

This is by far the most important and also the most difficult. This step is about clarifying your specific use cases. Say you have chosen a technology to solve a problem you are facing. Here are the questions you want to ask yourself:

Who will affected by your technology choice? Your customers, your internal software development team or your technology partners? What matter to those users? How will they access the technology? What are they currently using?

How will you use the technology? Are you building something with it? Are you integrating it? What are you building? What features do you need?

Your requirements should be driven by customer data, surveys or interviews.

High tech use cases:

For core web programming languages (Ruby, PHP, Java, Python, etc.):

Your first user is your customer: they will access your web server using a web browser (Chrome, Firefox, Safari, etc.). They expect HTML/Javascript/CSS. Your options should exclude programming languages are poorly equipped to do this (for example C, C++).

The second user of the technology is your software development team. What skill do they have? Are they comfortable with the technology? What tools do they already know that can leverage one those programming language?

For mobile technology (native, mobile web, PhoneGap, Titanium, etc.):
What mobile hardware do your users have? iPhones, Android, Windows? What type of app will you be building? Game, data? Does your app need to work offline?

For data storage (SQL, NoSQL, etc.):

What data will your customers want to save? What’s so specific about this data? Is this data structured or unstructured? How much will they want to store? Sometimes you will even need to segment your users: those who will read data and those that will write it.

Basic criteria for technology evaluation

In addition to who and how, you may also want to consider criteria from the basic list below:

Speed performance
How fast is it?

Resource performance
How much memory does it consume?

Initial costs and usage costs
How much does it cost? What’s the licensing scheme?

Ease of integration
How easy will it be to integrate the technology to my existing setup/infrastructure? What integration/development work is there to do?

Quality of support, documentation How easy is it for you to find resources on the technology? Who can help you when you need it?

Community
How big is it? Who else has adopted the technology? Do they help each other?

Availability of skill on the market
Do you need to hire someone to help you? How easy will it be to find one?

Maturity of technology How long has the technology been around? Does the technology have well known customers?

Future growth How actively is the technology being worked on? How often is updated?

Lock-in In a worst case scenario, you may have to abandon your first choice. How easy will it be to switch to another one? Is the technology using an open standard?

Low tech use case: transportation in Ho Chi Minh City (HCMC)

Motorbike are popular in HCMC to say the least

When I first arrived in HCMC, I had to decide a day to day mode of transportation. The city clearly favors motorbikes. However, I wasn’t convinced it was my best option.

I was the primary user affected by the technology choice. The problem is that I didn’t know much about how I was going to get around the city: I didn’t know where I was going to live, where my office was going to be, which neighborhood I would want spend the most time in, etc. I needed data.

At first I used taxis. It was the most flexible option. It required no upfront investment and had no term commitment. Then, I logged every places I went in Foursquare for 2 months. With that historical data, I created a map that helped understand my most frequently visited places and used itineraries: this gave me a radius of where I had spend most of my time. This radius became my primary requirements for my transportation decision.

Finally I wrote down the requirements for my use case:

I travel mostly within a 5 km radius

I want to be able to start my ride quickly and spontaneously

I want to travel quickly in the busy streets of HCMC

I want the transport to be environmentally friendly

2. Research technology providers (options)

Google first! Someone may have done the research for you and written a nice blog post about it. The keywords “comparison of X technology”, “X VS Y VS Z”, “Review of technology X” will help your search. Make sure you also go to the feature page of the technology provider.High tech use cases:

For PHP frameworks: “Comparison of PHP frameworks”

For Javascript MVC frameworks: “Angular VS Backbone VS Knockout”

For mobile tech: “PhoneGap review”

Low tech use case: transportation in Ho Chi Minh City (HCMC)

It was quite easy to list all my transport options: I simply stepped outside. HCMC is an Asian megapolis with cars, buses, taxis, motorbikes, bicycles (and a Metro by 2017-18!).

3. Compare options

Using your requirements, create an excel spreadsheet.

Populate the spreadsheet in the following way:

Rows: list of technology option

Columns: list of criteria and importance of that requirement (I use a weighing scale of from 1 to 5. 1 is not important, 5 is very important)

Fill each cell with a score: how well does technology X able to fulfill requirement Y?

Multiply sum the weighted score of each criteria for a given technology. This will give you a overall score for technology fit.

In some situations it maybe interesting to consider two additional options:

A combination of two technologies: in some cases, two different technology play nice with each other. You can combine the two to leverage the strengths of each.

Building a custom solution yourself: in some cases, there are no technology solutions out there. Beware that there is a very high cost to maintaining a technology on your own.

The outcome

Sometimes there is a clear winner. That winner will confirm your hunch.

Sometimes there is a tie or a 2nd place option with a very high score. In that situation, meet with your team or advisors and talk it out. Still undecided? See #4.

Low tech use case: transportation in Ho Chi Minh City (HCMC)

Below is the spreadsheet I created for my transport use case.

4. Still undecided? Give it a try.

Undecided?

Not everything can be done with research. You may have a list uncertainties or doubts. You may need to dig deeper. You may just need to try the technology.

In the Agile software world, we call those trials: “spikes”. Spikes are time limited experiments: the ideas is to use the technology within a short, well defined amount of time (often 1 day to 1 week). The goal is to clear up your main uncertainties and doubts.

High tech use case:

For Javascript MVC frameworks: one of your requirement may be a simple learning curve. Build a simple Todo app with Angular or Backbone.

For mobile tech: one of the your requirement maybe speed. Build a basic version of your app that focuses on your most resource intensive operations.

Low tech use case: transportation in Ho Chi Minh City (HCMC)

If I had not found a clear winner, I would have rented one of my two top options for a month or so: motorbike or bicycle.

Conclusion

Making key technology decision can be difficult. Even Facebook took the wrong decision. I hope this process will help you.

Keep it mind that technology evolves constantly and that your choice is only temporary. You will need to upgrade or move on to a new one in the future.