Guidelines

5 more things you should consider when selecting a new technology

This is a follow up to a post i did about one week ago, that I wrote to give some guidelines on how to handle the problem of selecting a new technology.

1. Scaling

There are two kinds of technology scaling I want you to consider. Performance scaling and price scaling (if you have to pay for the technology).

Lets begin with performance scaling. To begin to understand if performance scaling is relevant to you, you first have to ask yourself of the specific requirements the technology has to fulfill. If the workload of your technology is depending on some exteriour aspect you can not influence, you have to think about performance scaling. For example, you evaluate a library that allows you to detect duplicates within a set of address data. The address data is growing over time and when looking at old data you can estimate the grow rate over a year. Based on this information you should be able to define the following requirement: The library should be able to handle X times the address data without any relevant performance impact and therefore is useful for X years. This requirement allows you to put the technology into the perspective of your (probable) future needs. You should not buy into a technology you know is going to fail if your predictions come to pass. If I would have to phrase it very simple, always ask yourself “Can my technology handle future needs that are likely to happen?”.

Now lets take a look at price scaling. The same principle as performance scaling applies. If you can predict the workload a technology has to handle, you can predict the costs involved. And if you are on a budget, you should check pricing tiers. A technology might be cheap at a low tear and is getting exponentially more expensive in higher tiers. Or it might be a bit more expensive from the get go, but does scale with much less increasing costs later on. This applies to some open source technologies, too. Sometimes some really useful features are just available through a enterprise or professional pricing tier. So look close and plan a little bit ahead.

2. Marketshare & Popularity

A relevant factor is the current marketshare and general popularity of a technology, which both usually lead to a big community. A technology with a big community ensures that every problem you might have when using it, has already been solved and documented by someone at an online development community like Stack Overflow. But be aware that the current status quo of popularity or marketshare might not give you the whole picture. Try to find information on how the community is currently developing as well. Is there a decrease (like MySQL) or does the technology have a small community right now but is currently getting more and more popular.

I would suggest not taking this factor into account too much. If there is an awesome technology you discoved which covers all your needs, but is so new that it didn’t even have the chance to develop a community – try it anyway. When it is that good, a community will form eventually. If you don’t and choose a more conservative solution (although it is not as good), you might contribute to a classic chicken and egg problem. No one uses the product because there is no community and no community is evolving because to few use the product.

3. Open Source vs. Proprietary Software

A quick web search for “Open Source vs. Proprietary Software” results in many many blog posts and articles written about this topic. Therefore I wont go into much detail here and just state my personal opinion on this topic.

Usually I prefer using an open source solution, because those provide the best documentation you can get: the code itself. This is often comes along with an open bug tracker, that allows you to evaluate a technology in more detail before using it. If some obscure error comes up, you can usually find it already reportet, report it yourself or sometimes provide the maintainer with a solution.

But when I choose a prorietory software, usually one (or more) of the following is the case:

  • There is no open source solution available at all.
  • There is an open source solution available, but it lacks refinement or is not as ready for a production use.
  • The company providing the software is very trustworthy of highly investing resources into the product for the forseeable future.
  • I already use another product of the company and it integrates very well with the new technology.
  • The technology is very complicated to use and may require a professional support in order to integrate it faster.

4. Production Readiness

When selecting a technology you want to use in a professional environment, you should always research if the product is ready for production.

The most basic thing, is to look for stable releases and if there are none, look for any information about the production readiness a technology owner is providing. Usually there is some information to find on the web from the developers. If your project is going to heavily rely on the new technology, you might even take a look if there are any long term support (LTS) versions of it. These versions ensure a support with bugfixes until a given date in the future.

Another aspect is security. Check the documentation if there are any sections about security settings with some guidelines. Depending on the type of technology you are using, there might a lot of things to consider. Some technology might have everything setup secure up front and others are very “open” by default, which means you have to do extra work before deploying it in a production environment.

When working with technologies that deal with some sort of data, look if there are any backup solutions or other failsafe mechanics. Check on how flexible they are and how fast they can handle big chunks of data.

Last but not least, check if there is some kind of monitoring ecosystem available – if you look for a technology that provides some kind of real time service. Sometimes those are part of a enterprise program (e.g. MongoDB) or you might find plugins for monitoring services like NewRelic.

5. Does it really solve my problems?

This should be obvious, but it sometimes is not all that easy: Does the technology I consider to incorporate into my project really solve the problem I have?

This problem may occur if you deal with commercial software, where the specific capabilities are marketed a bit fuzzy. You might want to use a specific featureset when solving the problem at hand and the technology is presented to be able to support those features. But when looking closer (maybe through the documentation or via a request to the company), you might learn that the featureset is supported in a very limited fashion and is actually useless to you.

Another example are technologies that depend on other technologies. For example, you incorporate a library to solve an issue you have. Upon a closer look you might find out, that it is not the library itself that solves the issue, but another library, which it depends on. Threrefor you could “scale down” and use the sublibrary and not a superset that does not offer any more value to you.

These are just two very simplified examples. My general advice is to always ask yourself the question “Do I really understand what the technology is doing?”. And if the answer is “no”, keep on researching.

Leave a Reply

Your email address will not be published. Required fields are marked *