Late last year, we conducted an internal survey on what our people think of the current technology scene. We asked them to classify technologies based on their knowledge and how they see the future. We used three out of the four categories in the ThoughtWorks Technology Radar:
- Adopt: We know it works, we know it's great, we use it for real
- Trial: Test, learn, follow, poc, analyze
- Hold: legacy, hold from using if possible
This radar doesn’t, however, reflect the reality of our projects. We collect a lot of information on the technology stacks in the Web and REST API projects that are started each year. In last year’s new projects Play Framework and Scala was clearly the most popular backend platform. As always, there were some Java and Node.js projects, but in 2014 Clojure started to gain traction in our projects, too. In those projects, React and AngularJS seemed to be equally popular among the frontend stacks.
Our stance on technology choices
Over the years we have witnessed a lot of technologies come and go. Mobile business is a good example - we used to do a lot of projects on Symbian and MIDP platforms, but were luckily among the first in Finland to start working on iOS and Android projects.
At the end of the day, we really don’t want to commit to any single technology stack. For us technologies are tools, not a strategy. This is an important part of our promise to our employees: at Futurice, developers can have an impact on which tools they use and learn new technologies. We select tools based on our customers’ needs, not on partnerships with third party vendors.
For us technologies are tools, not a strategy.
Especially in bigger projects, we are proponents of microservice architectures. This means clear APIs and good tests between services. We support the use of open source components and give back to open source projects via the Spice Program.
All this prevents vendor lock-in and creates a good basis for further customization of tailored solutions. Sometimes this results in heterogeneous technology choices. We keep our eyes open for changes in the technology scene, so its easier to see failures in past technology stack choices. In an optimal situation, we can then rewrite a single microservice component with another technology – instead of having to re-implement the whole service. In our experience, heavy refactoring or even rewriting some parts of longer-living, complex software systems is an eventuality rather than a possibility. Microservice architecture minimizes the impact of that eventuality.
These are, of course, never easy decisions and the nature of the service being built has to be taken into consideration. Are we building a short-term, new digital service or rebuilding an industrial production management system that’ll be used for the next 5–10 years? In both cases the service needs continuous development and collaboration with end users to offer optimal value. Being able to select the best possible technologies is the best way to serve that goal.
In the past, we’ve based a lot of projects on products like Drupal and walked the rocky road of trying to bend the product to fit use cases it was never meant for. An effective way to solve a common use case like content management is with a CMS product, but the customer usually wants to offer a very specialized service with a world-class user experience and usability. This is very hard to achieve with an off-the-shelf product. We will soon publish another blog post on some good recent experiences on how to combine products like Drupal or Prismic.io with a tailored presentation-level implementation.