The technology balance

When it comes to choosing technology for a new project, it is often tempting to choose the latest and the brightest stack. On the other hand, many businesses tend to fall back to something proven, well-known and usually outdated. In my opinion, neither approach is perfect and as engineers we always need to find the perfect balance between innovation and stability.

To illustrate the point, let's think about hardware. If you look at the price range of the latest CPUs, you'll notice that once you get to high-end selection the price starts to increase exponentially. The actual processing speed gets better as well, but only gradually. This makes perfect sense, because the technological process of manufacturing new chips is not yet established and production lines don't work as efficient. Inevitably, after several years, as manufacturers discover new (cheaper) ways to increase the output efficiency, the price of high-end models drops dramatically.

A similar thing happens in the software industry, but there is an important difference. Whereas a high-end CPU is definitely better than its cheaper counterparts, "new and shiny" technologies are routinely proven as anti-patterns only months (sometimes years) after the initial craze is subsided.

It is especially true on the frontend where new stuff gets released almost every day and deemed outdated or "wrong" just as quickly. A good example of this phenomenon is CoffeeScript, which came out several years ago and tried to fix some of the bad parts of JavaScript while introducing some novel features along the way. In 2018, it's not even considered a viable choice anymore and it makes certain big projects (such as Atom), which doubled down on CoffeeScript a while back, pretty awkward.

In this day and age, it is surprisingly easy to end up with a legacy frontend application even before it's finished. One European bank, for example, recently finished revamping its UI using AngularJS only to realize that Google already deprecated it and the new version of the framework is a complete rewrite. Ouch.

This logically brings us to the question of outsourcing. Can you outsource the creation of a Web-site? Absolutely, and as long as you are perfectly happy with mostly static content on the home page and the simplicity of overall design, the WordPress-based site will work perfectly well. The same reasoning can be applied to so-called "throwaway prototyping", a phrase coined by Fred Brooks in his well-known book "The Mythical Man-Month". However, there is an important caveat. As Fred Brooks himself admitted recently, the idea of creating something with the intention of throwing it away is wrong, because it's overly simplistic. And indeed, in this scenario, you run the risk of creating a completely dysfunctional system that doesn't present much opportunity to learn anything from it. As a result, as Ward Cunningham suggests here, you'll have to build the prototype twice, probably with disastrous consequences for the business.

What should we do then? In my opinion, we should try to create a reasonably flexible system that works well under a reasonable load. This flexibility will enable us to adopt it to future changes while serving perfectly well the current need of the business and its customers. For many startups, the reasonable load could be just about 10,000 concurrent connection and, quite honestly, with modern hardware, this is pretty easy to handle.

This is one of the reasons I like Scala and React. These technologies are relatively stable and give the developers an enormous amount of flexibility. Scala, in particular, is a very good choice for a backend language as it allows programmers to move very quickly while preserving type information and keeping accidental complexity to almost zero. The Play framework makes a great choice as a foundation for a backend stack as it has a ready-to-use solution for pretty much any problem out of the box. While Java is making a good progress at becoming a more productive language, Scala is still miles ahead which is well illustrated here.

Similarly, React is a very capable library and, unlike some other frontend solutions, its API has been stable almost since the inception. The ecosystem is also quite enormous and there are usually several good choices for any task. And the final argument is React's great support for server-side rendering, which we successfully employed in our projects (one such example can seen here).