While working as a full stack web developer (or any other type of software developer) you will often have to incorporate some new technology, library or software to solve a problem for your current project.
In some cases there might be only one clear path ahead of you, since there is only one de facto standard solution everyone uses and considers to be almost perfect. But more often than not you have to pick between a variety of solutions. Should I go with Solr or Elasticsearch? AngularJS or React? MariaDB or MySQL?
This post will provide 5 indicators you should be aware of when you need to select some new technology.
This minimizes the risk of picking a technology you have to throw out the window after a few weeks because of its shortcomings. Or even worse: You have to keep it and have to work around the problems for the next few years. This wastes money, time and your energy to actually create something awesome, instead of monkeypatching stuff that should work right out the box.
The following indicators are not a complete list and they are not ordered by priority in any way. I am going to collect some more indicators in a future post (probably next week). Nevertheless, I hope the ones presented here are already helpful to you.
1. Age, release cycles and “up to dateness”
You would not use some old and expired food to cook your lunch. The same principle applies here. Do not use something that has its last major release years ago. And if you have to, just be sceptical and research why this is the case. The technology might be so simple and future proof that it does not need any extensive updates, but that is very rarely the case.
Also check the time gaps between releases. Does the project have regular major releases? Do critical bugs get fixed close to beeing discovered? How fast are updates of underlying technologies supported? For example, how fast does the library in question support the new version of the programming language it is built for.
When dealing with open source projects you can search for the code repository and get a pretty good idea on how fast a technology is moving foward. For proprietary projects Wikipedia might help you, since it provides a version history for the more popular technologies (e.g. MySQL).
The general age might also be a helpful indicator. Technologies that are more recently created tend to be more in line with modern requirements and have less dead weight attached to them. Older technologies might have a bigger community around them and more mature development tools in their ecosystem.
In my opinion the scope of an incorporated technology should be as focussed as possible. If I have problem A to solve, I would prefer a technology that solves A. Not the the one that solves A, but also B, C and D.
I like it because:
- The maintainer probably focusses more on the further development to improve its solution of problem A and you might get performance or feature benefits.
- In case you are paying for a technology, you can compare it better to its competitors and evaluate the return of investment in much more straight forward way.
- Example: You need problem A and C solved and use a technology that solves both (and maybe more). But as time moves forward you get more and more dissatisfied with some aspects on how C is solved. You want to use another technology that solves C better. But your technology does not provide a clear interface to separate its functionality and you have to re-solve problem A as well with yet another technology. This is especially problematic if you pay for the product and gets more and more complicated (i.e. expensive) the more problems the original technologly solved.
- You will gain more independence from the technology owner. Not liking where a technology is heading towards? Pricing is beeing increased? This will be much less of a problem if you picked the technology that solved only one main problem. You just switch and adjust all the interfaces.
Something else I try to avoid are commercial products that fail to tell me what the scope of their product actually is when checking their website. Instead you are welcomed with warming phrases like “Global Ecommerce Solutions” and have problems to find the information you want, like pricing or a list of features. I get why companies do this, but for me as a developer this always looks like the company wants to obfuscate the actual features of their product(s) in order to seem more worthy the (probably high) price they are charging.
If you want to have a bad day, try to install and integrate a technology that has no documentation at all. Or a myriad of different documentations that may even contradict each other. The PayPal documentation used to be a good example for a serious clusterf**k. There are a lot of bad examples out there and I am sure you had contact with at least one of those cases, if you are working in software development.
That is why I prefer technologies that are well documented, by providing a clear user experience for a developer who has to use it. The MongoDB documentation is a good example for a documentation well done. Sure, it could be better, but let’s be realistic: It will never be perfect.
Another dealbreaker might be a deprecated documentation, no matter how good it is. If I want to use technology, go to the documentation and realize that it is one or even more major versions behind – I am out and come back until it is up to date. I try to avoid the hassle of going through the documentation and upgrade information (if it is provided) at the same time. If problems come up, you always second guessing yourself if you are doing something wrong or if things have changed and are not beeing documented yet.
4. Use existing comparisons
If you evaluating technologies that have some competitors in the market, search for comparisons. Usually there are some blog posts that tacle the issue. Or you can visit the owner’s website of a commercial project and look for a “What we are doing better than X!” page – although they are biased, of course. Sometimes there are even Wikipedia articles on some topics, like this one on web frameworks.
Besides the raw data, this method might provide you with some additional points you didn’t even consider to be a relevant aspect when starting to look for a technology. For example, this could be an interface to another technology you are already using and you had no idea could be connected.
5. Research for technology name + problem(s) and check bug trackers
A quick google search can spare you months of headache. Just type in the name of the technology you want to research in conjuncture with problem(s) and you can get a really fast grasp on problems other developers have. You might see a dealbreaker right away or you might be eased that you see nothing serious. This also gives you a good overview on how complicated it is to actually install or use the technology. “XY won’t start” might be an indicator that the installation process is quite complicated or badly documented.
Just be aware of the age of some posts. The technology might have already solved the issue.
If you deal with a technology that has an open bug tracker, check it out. Look for long lasting bugs, open feature requests and of course the general amount of issues. You don’t necessarily have to dig into each issue, you just need to get an overview on how much is going on there and ask yourself: I there a general problem?