A week ago I opened a poll on Twitter:
Today, I would like to discuss these number and what adopting a new technology entails.
It's important to mention that the majority that follow me are iOS developers. Generally speaking, iOS developers are fanboys towards Swift, Objective-C and the "superior" user experience provided by the iOS native system. It's indeed a double-edged sword. One one hand you have engineers that want to offer the best to the user. On the other you have a group that is quite defensive about the technology they use.
Abandon shipoption, is clearly over exaggerated. 37% means that almost 4 in 10 engineers in a team would leave. Generally speaking people are more reasonable, at very least because they also have bills to pay. Even in a market like London, finding a good gig can take months. Because voting on the internet has no practical consequences in one's life, a good amount of voters prefer drama over reason.
- Flutter at 41% was a big surprise to me. Most engineers that I have spoke with, said that it offers a great development experience. The performance is also pretty decent. I do wonder however, what led ReactNative to go so low at 17% of votes. My hypothesis is that some of these articles hit its popularity hard. But it still doesn't explain why Flutter has almost 2.5X times the number of votes. As someone mentioned, it seems that my poll reached a bigger number of Flutter enthusiasts, compared to React Native. I do think this is a more plausible explanation than technology for technology's sake.
- There are some honourable mentions to Kotlin and Xamarin, but not particularly exciting. Nevertheless, I trust much more JetBrains, than Google or Facebook.
There are other considerations, when adopting a cross-platform technology, that seem to be oblivious to people that have the executive power to make such decisions:
- Is the problem well understood by everyone involved? The first question you need to ask yourself, is why a cross platform solution is the right choice. And by right choice, articulate what's the problem that a native solution cannot solve or provide. If you cannot convincingly and objectively answer that, you are not solving a problem: you are creating a new one.
- If you don't have the buy-in from the majority of the team 1, the adoption will be difficult and met with resistance. Not only that, the output will suffer, since people are forced to do something they didn't signed up for. There's also a good chance, as the poll showed, that a percentage will be more interested on updating their CV and Linkedin profile than actually working.
- Assuming buy-in is not the problem, is the team capable of dealing with both the transition period, but also be able to perform on the medium to long term. What's the alternative in 3 months if the team hasn't been able to get up-to-speed? Is there a backup plan if this fails? How easy it is for the current code to integrate with the new solution? What about on-going work and existing deadlines?
- Is it easy to hire experience engineers in the given technology? Recruitment is a big factor when scaling teams (e.g. it doesn't matter how good Haskell is, if you can't hire Haskell developers). If the team has experienced engineers in the technology, this will ease the transition.
- Is the technology you are proposing able to meet the challenges of your app and business? Is there a plan in place that audits the major features of your app and proves that this new technology can solve them? If the goal is to leave more sensitive pieces natively, do you have the expertise of native developers still around?
Changing from one technology to another can bring great results, if the process is done in a clear, transparent and honest way. Those results can vary in spectrum from speed to market, reducing costs and, often understated, engineering happiness. Doing such reorganisation in a surreptitious way is no more than self hubris and incompetence.
1. The expression "majority of the team", is a nice a way to think democratically about the problem. The reality is more nuanced than that. You don't necessarily need the buy-in by the numbers, but by the most influential individuals. There's a lot of literature about "power dynamics" in teams, that I advise reading.