Making the right technology choice for a project requires knowledge and experience. Our Technology Director Mikko shares some general tips that will save you many sleepless nights.
Making the right technology choice for a project requires knowledge and experience. Our Technology Director Mikko shares some general tips that will save you many sleepless nights.
As a company, we strive to find and use the most relevant technologies to solve our customers' needs. At the same time, we need to keep in mind that these technologies should be available and supported for the foreseeable future.Almost all of our technologies are open source. This means that we get to take a peek inside the tools that we are using. Moreover, in case we encounter problems, we can see where they might be and fix them ourselves. Or, if we are missing a key feature we can just build one on top of these libraries or tools. These tweaks often come in handy in future customer projects. We also make many of them publicly available for the developer community as well.
To really be able to see what new technologies or tools should be taken into consideration, one needs a good understanding of their inner workings. If you have exposed yourself to a good CS education (or built up similar knowledge by yourself), you can immediately see what basic principles are in use and what benefits and drawbacks they have. A vast amount of ideas implemented today have emerged from the 1960s and 1970s CS papers.
Beyond that, it is just basically a matter of following the progress of the work put into the technology and trying it out in your own small scale projects or in a fitting commercial project where you can easily fall back to using older tools to solve the problem if something seems to go awry.
Seymour Cray was famous for using old and stable technologies to build his supercomputers. This made them very reliable. The one time he decided it was time to be "the pioneer" it failed.
It is advisable to always try to see how the new technology is progressing, how people are starting to use it and what kind of issues arise. A real-world example: I'd had React Native under my radar since its conception, but for quite a while felt that there were some initial issues with getting the thing to actually work, and providing meaningful end results without constantly breaking things to the end users with every release. This has improved so much in the past years that eventually I started to trust that we could start building our applications on top of the technology. So far it has been a good experience, with some minor hiccups trying to upgrade from 0.55.4 to 0.56 (eventually we jumped straight to 0.57 and all of our issues disappeared).
If something feels like magic, it's probably just marketing.
There are several good examples of technologies that have failed in their core promises in the last years. The most of them come out with a lot of marketing and have built up promises that they cannot keep. If something feels like magic, it's probably just marketing. We all live under the same laws of physics (and the laws of the Big-O).So, always examine thoroughly what is being promised and how everything is explained. There are almost always some assumptions or some shortcuts that are employed when something that has seemed very hard or even impossible and is now promised to be easy. As always, look for opinions from the actual users of the technology; what their use cases are like and what their experience is.
I am very happy with our current technology stack. Mobile clients are implemented on top of Xamarin using C# programming language or React Native using ClojureScript programming language. On the server side, we are relying on Python and Clojure programming languages, Django Web Framefork and most of our data storage solutions are based on PostgreSQL. These are very solid products, and even in case something breaks at 3am (that has not really happened in a very long time, to be honest (knock on wood)) we know where the problems might be and be able to solve them swiftly.
I am especially fond of our current front-end stack which is based in Reagent and Re-Frame libraries that are built on top of React for ClojureScript. The development experience using Figwheel is something that, once you experience it, makes you never want to go back.Of course, there is always space for improvement and we are experimenting on building abstractions and conventions ourselves on top of these tools. Maybe we will discuss them in another blog post in the future!
Want to see our full current tech stack? Check out our development services page.
Interested in development jobs? See our open positions.
