How to evaluate a software stack

Update (2020-06-25): I've updated the section on Flutter after having evaluated it further.

Imagine a product manager at a company where the job is to drive the development of one of the key software products. This person might have some experience in software development as well, but these days they defer all technical decisions to the engineers in their team.

After a keynote from a large tech company, one of the engineers approaches the PM with this new shiny framework that they claim is the new future. It will solve everything, reduce development costs and it is, according to the engineer, definitely the right choice for the company going forward.

Most PMs have probably had an experience like this. How would you react? Your own technical skills might not be up-to-date to determine if this is a good thing or not, so what should you do? You could leave the decision to the engineers and hope they are professional enough to do so. The problem is that your engineers aren’t usually very concerned with the non-techincal aspects of choosing a framework.

While I won’t claim to have a perfect recipe myself, I have watched several frameworks come and go over the years and have a checklist that I try to apply when making this kind of decision myself. It’s simple to follow and doesn’t require a deep technical knowledge about the domain. It doesn’t give a clear answer, but it will hopefully help you feel more confident about your decision.

What can history tell us?

In 2007, Microsoft announced the Silverlight application framework. It was a direct competitor to Adobe Flash and promised to be better than that in all aspects. Today we know that it didn’t succeed very well and its demise was announced already in 2012 when Microsoft announced the end-of-life for the technology. Despite this, large companies like Netflix and Amazon used the technology for streaming video on the web, until it was replaced with HTML5.

Adobe Flash has a similar history, but over a longer timespan. When Macromedia acquired FutureSplash in 1996, they renamed the technology to Flash and it soon became the de-facto standard for interactive web applications, until HTML5 came along.

The history of both Flash and Silverlight tells us a number of important lessons when it comes to technology stacks.

Their initial success depends a lot on the developer experience. Flash had a number of competitors, but none of them made it as easy to develop applications as the tools from Macromedia (and later Adobe) did. You could create the same types of applications using Java Applets, but the Java stack was nowhere near as successful for interactive web applications as Flash was.

But the developer experience needs to be significantly better than the competitors’ in order to gain traction. Silverlight was better than Flash in this regard, but not better enough to motivate a significant change in the industry.

All proprietary technology stacks will eventually become deprecated. Open technology stacks can also be deprecated, but that doesn’t necessarily have to happen. The important thing to learn here is that the proprietary stacks will always get deprecated, eventually (usually sooner than we expected). There are numerous examples of this. Nokia betted on Symbian and then Windows Phone, while Samsung went for Android.

However, being open-source technology is not sufficient for a stack to become successful. It also needs an organisation that drives the evolution and has a clear way for anyone to propose changes. A huge drive for the success for Java has been the Java Community Process (JCP) and the Java Specification Requests (JSR). While Java wasn’t fully open-source (at least not in the beginning), the processes for evolving it were open for the public.

My method for evaluating the potential success for a technology stack builds in these factors: Developer Experience, Openness and Standardisation Process. These are not binary components, but rather are rated on a continuous scale that ranges from fully satisfactory to unsatisfactory. Let’s see how they would apply to the technology stacks that we see are popular today.

Evaluating React

I’m going to be bold and start with the most popular web framework in use today, React. You might not agree with my conclusion, and only time will tell if I was correct.

Speaking to web developers today it is clear that React has a huge popularity in the community. Almost all companies I go to work for today have a front-end team that uses React. When asking developers why they like it they almost always mention the things around developer experience. Almost nobody claims the performance or other deep technical aspects as the main reason for using it. Developers love React because it’s easy to use, you get stuff done faster and the tools are great. Looking at the developer experience, few frameworks rate as high as React does. This should be the goal that everyone building a framework should strive for.

React was created by Facebook who is still very much contributing to the major part of its development. It’s completely open-source and anyone can submit PRs or issues on their GitHub repo. We can say that it rates high on the openness scale. However, the decisions about its future is aren’t very clear beyond what Facebook writes on their blog, so it won’t earn a gold star regarding openness.

React is not based on a standard, but on a non-compliant fork of JavaScript called JSX, and there is no clear process for submitting changes to the technology stack. It is, by definition, a proprietary technology although it’s developed in the open. You can submit at PR or file an issue, but Facebook hasn’t provided any clear way for how changes should be proposed or decided upon. This is not an immediate problem, but it most likely will be in the long run. When the community can’t easily engage in the future development of React, they will eventually turn away from it. On the standardisation level, React ranks fairly low.

In many regards, React is very similar to Flash. It provides a great developer experience but it’s not standardised in any way. The biggest difference is that React is open-source when Flash wasn’t. But this aspect weighs lightly when it comes to long-term success.

So what would be my judgement for React? If you’re starting a project from scratch today, I would advice against React as I’m concerned that it won’t be able to keep up with the upcoming competitors for the next few years. Developers will instead turn to the technology that provides the better or equivalent developer experience and businesses tend to look at things that are standardised. Look for technology stacks that are built on the open and standardised web technologies (like the LitElement project using Web Components) for a more future proof web stack.

Flutter

The cross-platform framework from Google scores fairly high on most aspects. It has a very good developer experience, it is based on the standardised language Dart, and everything is available as open-source. Google is also fairly open about the development of application framework itself.

However, its developer experience is not significantly better than the competitors, it’s not much more open than others and the standardisation of the platform is only on the programming language part. Flutter is basically in the same position as Silverlight was. It’s a great technology, but there is a risk that it is too little, too late.

Update (2020-06-25): My initial prediction about Flutter was wrong. After having evaluated Flutter further and also worked with it on a real production project I can say that it is definitively a valid candidate and will likely have a long term impact on the client-side development. It is not the best option for all types application, but as a cross-platform framework it is probably the best choice today.

Kotlin

With an open-source repository, clearly defined standardisation process, and amazing developer experience, Kotlin will most likely become one of the top programming languages used in the world. I would not be surprised if Kotlin eventually will make the Java programming language obsolete, at least for new projects.

Rust

The programming language from Mozilla has shown to be very popular as an alternative to C and C++. The developer experience is excellent and the documentation of the language and standard library is probably the best found online today. Rust also has a very clearly defined RFC (Request For Comments) process for deciding on new features and changes to the language. This technology will most likely survive the test of time and find a use in lots of different areas.

The exceptions

There are always exceptions to these kinds of guidelines and it’s hard to define when those apply. Looking at iOS and considering how it ranks on developer experience, openness and standardisation, it’s clear that it scores very low on all of them.

Writing software in XCode is a joke compared to using anything from JetBrains or the Visual Studio Code editor. Swift is a good programming language, but others like TypeScript, Kotlin or Rust are far ahead of it. The toolchain is a mess compared to what is available for the web, or Android. At the same time, there is zero communication from Apple on what is the roadmap for Swift or the OSes it’s so closely coupled to, iOS and macOS. There is no public process to influence the (secret) roadmap or the language itself. The Swift programming language is open-source, but there is no clear governance or process for driving changes. With all of this in mind, iOS should have failed a long time ago.

The difference is that Apple builds products that are amazing and state-of-the-art, and developers have no choice but to support them through the tools provided by Apple. Similar situations can be found elsewhere. Bluetooth is a horrible standard in many perspectives, but it has become so engrained in the industry that we have no choice but to support it for the needed use-cases. When things depend on the world outside of software and are not easily replaced, they tend to stick around longer than we expected (or hoped).

The lesson here is that a bad technology stack can survive if it is impossible or very difficult to replace it with something better. The frameworks we use for our backend or frontend projects can easily be replaced, but the operating system for hardware is much harder.

It depends…

By looking at the three factors of Developer Experience, Openness, and Standardisation Processes, you have tools for evaluating how good of a choice a given technology is. However, this is just an evaluation and there are other factors that remains to be considered. A new technology might score high on all of them, but the target environment (hardware platform, etc.) might be so obscure that the numbers are basically irrelevant. An older technology might score low, but it remains dominant in its field because of reasons outside the software domain.

However, for software projects where you need to decide on a technology stack it usually tells a lot. Your project also has a timeframe that affects your decision. Choosing React today could still be a good choice if that is what the developers in your team knows. If the existing code base is in Java, it might be better to stick to that language and not switch it with Kotlin for now.

As usual, it depends.