How to choose a technology platform

In wine there is truth.

One of the most impactful decisions in a project is deciding what to use for the underlying technology. At Terem we like to believe that choosing a technology platform is like choosing a wine paring. Delicious.

I am no expert on wine. Perhaps it’s best to address that at the outset. But even a curious amateur can appreciate a fine choice in wine. I can enjoy a light white wine paired with grilled fish, even if I am too inexperienced to articulate the logic behind this. It recently occurred to me that selecting a technology platform is much the same as selecting wine. Some technologies pair well with certain projects, complementing requirements and simplifying implementation. Some technologies are best served if cellared for a few versions, allowing the product to mature before their introduction. And other technologies are perhaps best relegated to semi-fond memories of youthful inexperience.

Every course of a meal and every stage of a project requires carefully considered choices. And just as sommeliers use their knowledge of food and wine to provide complementary suggestions, we at Terem do the same with technology. One of our recent project briefs required the design of an android app. The team had to choose between building the app on the mature and well supported platform Java, or using the fresh and efficient architecture of React Native. But qualitative assessments such as these, are not particularly useful in practical decision making. So let’s take a look at the process we use at Terem for quantitative technology selection.

Feature Selection

Just as a chef selects a menu to suit both their clientele and their restaurant, at the start of every project we determine a list of required features. While these features are typically selected based on the project specification and client input, the developer may also choose to implement standard features across all projects. These features can be generic, such as quality of life and test frameworks, or they can be project specific, such as Facebook Integration or Access iOS Address book. Regardless of their source, it is important to be thorough in feature selection. A more comprehensive list will allow for greater accuracy in assessing technology platforms.

Feature Prioritisation

Now that the chef has their menu, and we have our feature list, we can evaluate individual components and prioritise them accordingly. The sommelier’s cellar space and finances are finite, and their wine choices should be weighted to suit the most important menu items. Similarly, we as developers, can order our features by assigning each a priority score of 1 – 5. A score of 5 being used for the most critical project features and a score of 1 for relatively minor requirements. It is important to note that these priorities can also originate from the customer. Perhaps they place high importance on having a strong internal knowledge of a framework. Or maybe an internal mandate stipulates that their developers must have high job satisfaction, and they thereby require a high quality integrated development environment (IDE).

Feature Fit

Having developed our prioritised list, the next stage of the process requires consultation with experts. The chef with their sommelier, and the developer with their engineers. We typically gather a small focus group of engineers who have experience with the target technologies. They are asked to rate the ability of each technology to fulfil the requirements for each feature, using scores of 0 – 5. A 0 value specifies that the technology cannot be used to implement the feature, while a 5 is indicative of a perfect fit. Note that the feature fit rating can include factors such as the ease of implementation, the availability of established libraries and documentation as well as the overall architectural complexity associated with the specified technology.

Quantitative Technology Selection

It is vital that the priority and feature fit scores are determined separately, as this will ultimately lead to less bias. The importance of each dish on the menu should have no bearing on the suitability of each wine. Likewise, the ability of a technology to meet a particular requirement, should be entirely independent of the requirement’s own relative significance.

Once we have independently obtained our priority and feature fit scores, we can calculate a weighted score for each feature/technology intersection as specified below:

Weighted Score _{feature, technology} = Priority _feature × Fit _{feature, technology}

The sum of all such weighted scores for a particular technology, represents the overall value of that technology for the given project. All that is left is to select the technology with the highest total value as the project platform.

Of course sommeliers rarely outline the metrics of their flavour-based scoring systems. Perhaps the illusion of intuition is more appealing than the rationalism of arithmetic. For the developer, however, methodical and quantitative reasoning is always more valuable.

React Native, how do I find thee most suitable? Let me count the ways.

---