We often get asked why we don’t use a specific technology to implement our apps or applications. We hear comments such as “your competitor is using it” or “it is great, why are you not using it?” Call us old but the reasons are: we’ve been burned before and have learned our lessons. As such, we take adopting new technologies very seriously and have developed a selection criteria that new technologies must go through before we choose to select them in our projects. The criteria are:

Meet Requirements

It goes without saying that in order for us to select a technology, it must meet the requirements for the project in question. There is no point selecting a tool if it doesn’t help you meet your goal. It doesn’t matter how shiny, great, easy to work with a new technology is, if it doesn’t meet the requirements for our project, we do not select it. 

Improvement to Status Quo

Moving to this new technology / tool must provide some payoff or benefit that justify its selection. There must be a return on the investment. We do not switch just for the fun of it (it is rarely fun anyway). There is usually a large investment to migrate to a new technology, usually in time spent, so we don’t take switching lightly. We switch because it provides significant improvements in features, speed of development, or maintainability; however, in some cases we do switch if we are forced to because a technology is no longer maintained or supported which brings us to our next criteria.

Maintained & Supported

A technology must be well maintained and supported. We usually like to see that there have been updates / patches within the last year and that updates are usually done in a quick manner. If a technology is only updated once a year and takes years before fixing major bugs, it is not great. We also consider as important a published release schedule as well as clear guidelines on which versions are LTS (Long Term Support).

Ideally we prefer technologies that are backed by large companies such as Apple, Google, Amazon, Oracle, Microsoft; however, that’s not always a recipe for success as those companies do decide to stop supporting certain technologies. Case in point, Adobe recently announced they are no longer supporting Adobe PhoneGap. In general, sticking to technologies backed by hardware vendors is a good approach as usually the technology is their hook to sell more of their hardware. If they stop the technology, they will usually provide a replacement; otherwise, their entire hardware product line could be in jeopardy. That being said, there are plenty of open source solutions that meet our selection criteria that are not backed by hardware vendors.

Mature

As part of our selection process, we evaluate how mature a technology is. A brand new technology can look very enticing to start with but in many cases have major pitfalls, holes, or bugs that make working with that technology a major headache. For example, we have recently reviewed Amazon’s Honeycode service. As we concluded, although it is very promising, it is still too basic at the moment to meet the typical challenges of most technical projects. You could probably get going very quickly but then would soon run into a “can’t get there from here” situation and would have no recourse. We’ve had a customer contact us recently as they had developed a solution using a 3rd party solution but then got to a point where they couldn’t implement their next feature as the platform didn’t support it. They were stuck having to go back to the start.

That’s an important piece to consider because, even though a technology can meet your project requirements at the start, you must select one that is flexible enough to handle new requirements in the future that you haven’t thought of just yet. Typically mature solutions help with that as the more mature a technology is, the more requirements it can meet as it has been put through its paces by more than just a few users which leads us to the next criteria.

Significant User Base

In order for us to select a technology, there must be a significant user base of developers / people that know this technology. Having a significant or large user base prevents issues with the proverbial “gets hit by a bus” which this day and age likely means that the neighbours offered better vanilla flavoured coffee and yoga classes. Furthermore, having a large user base generally means that there are many forums, boards, threads where issues are being discussed and solved. Regardless of how great a technology is and that it meets all the other requirements, there will be times where manure hits the fan and you will have to look for some help. Having that user base to support you can result in major time savings when issues occur. That’s even more true when a technology is more mature as there are likely others that have run through the same problem. 

Dependencies

In order for a technology to be selected, we also take a look into the dependencies of the technologies and analyse the risks as well. Too many external dependencies can be a bit of a red flag. Also if they are reliant on obsolete, or stale dependencies we will also take a deeper look to see if they have a plan in place to work through these potential future issues. We’ve seen that some technologies have been held back because of their dependencies or end up with security issues that are not easily mitigated.

Selected Focus

This last criteria is more of a business decision. Before we select a technology, it must make sense to us from a business standpoint. As an example, we early on in the creation of 14 Oranges selected to create web applications and websites using the L.A.M.P. (Linux, Apache, MySql, PHP) stack (Note we have since evolved that stack but overall, this selection has provided the basis for what we use for our projects). Microsoft provides their own stack which also meets all the same requirements but unfortunately we do not have unlimited resources and having our staff interchangeably knowledgeable on the same technologies allows us to move staff from project to project as needed (another precaution for the proverbial “hit by a bus” problem).

Conclusion

As you can see, at 14 Oranges, we don’t take the selection of technologies lightly. New technologies are objectively assessed against our list of criteria to ensure we don’t end up painting ourselves in a corner resulting in costly rewrites or workarounds which in the end result in savings to you, our customers.