Migrating is hard, but starting from scratch is easy

I’ve been following Flutter since it was in beta, and since then I’ve seen Flutter’s adoption among developers, communities, and companies. Most emerging developers have discussed this issue at one point or another:

Why don’t big companies use Flutter?

Therefore, this small article is just my personal observation and answer to this question.

Moving to new technology is difficult and complex, while starting over with the latest technology is easy. This is (from my observation) one of the biggest reasons why large, stable companies won’t migrate their long-standing applications to new technology unless It can bring amazing profits.

You will find that most of the startups are using Flutter, this is because more than 90% of new ideas for cross-platform applications can be easily implemented in Flutter in a cost-effective manner. Everything in Flutter is very fast and amazing, And with all the amazing benefits we’ve heard about in our Flutter journey over the past few years.

So here comes the question:

Since Flutter is so amazing, cost-effective, single code base, easier single team management, delightful developer experience, and so on; then why don’t big companies migrate their applications to Flutter? Scratch that Start a migration or rewrite, have a single team, a single code, wouldn’t it be heaven?

No, it’s not that simple.

The Question: Business vs Technical Passion

Flutter is amazing, and you can finally convince developers in your company to build apps with Flutter. The problem lies in the company’s operational business. Businesses expect Flutter to contribute to the business immediately. They don’t want to wait for their teams to completely rewrite the app , and then put it into practice to prosper your business.

But as I said earlier, rewriting is ideal for the technical team. Therefore, this is a question that can be thought about by the company’s stakeholders. The company needs to internally analyze the area, business type, team culture, etc. After factors, find a middle ground.

Anyway, let’s see how these two scenarios play out.

Rewritten from scratch: technical aspects

A large company has a vast array of products that are integrated into processes and areas, work flawlessly, and get the job done for the business.

Technically, the best thing for the CTO would be to rewrite the app from scratch on Flutter and get it done. However, if they decided to do that, they would have to hire an entirely new Flutter development team, Explain to them everything about the current product/domain and ask them to rewrite the application. This may seem easy, but it’s not. There is a lot of internal knowledge in the current code base that must be passed on to the new team so that they can build a complete solution for the application. Same experience/UI/UX/flow.

Why is it so important to build the exact same thing?

This is because users will one day receive updates to Flutter-built apps for the first time, which is very dangerous for an app with thousands of users.

Secondly, new features are being built on top of the current app, and the rewritten app may not catch up with the current app. But this is a business decision (either to stop new development and do a rewrite first, or to continue adding features to the current app , the pros and cons must be weighed anyway).

Every company is unique in terms of domain, culture, people, leadership, thought process, think tank, etc. There may be hundreds of challenges internally that can only be understood once you get into the system. You can’t possibly know every tech company All present a single perspective.

Rewritten from scratch: the business side

When companies adopt new things, they have a very important idea:

Not only should the business not sufferduring the rewrite, but it should also keepgrowing.

This means that you cannot compromise on the functionality and development of the running application. In the rewritten version, the program should run normally without errors. To ensure this, rigorous atomic level testing needs to be done to ensure that users never There won’t be any problems with functionality that is mastered from the beginning (we are talking about big companies, which means the application has been running for years). We can do unit/integration/UI testing, but when it concerns business, money and users At that time, no one would be willing to take this risk.

In short, most stable companies will not decide to rewrite their stable applications in Flutter from scratch. If it is a project-based company, they may start newly won customer projects using Flutter.

Migration (business friendly, but technically unfriendly)

Another way the company decided to migrate to Flutter is to move to Flutter screen by screen and use the method channel to communicate with the local side ( Talabat’s application ). This may be a nightmare for the technical team, but for the business This is the most feasible approach in terms of continuous operation and allowing the Flutter part to contribute to the business from the beginning (during the rewrite process, the Flutter part of the application will not be of any use to the business unless it is brought online to production).

As a reader and Flutter enthusiast, you might think that screen-to-screen migration is amazing, but in reality, it’s really complicated when you’re working in a production app used by thousands of users every day. It’s like a craniotomy.

in conclusion

From my observation, it is very difficult for a product-based company to decide to convert its years of mobile development technology stack to a new technology stack. Therefore, if a large company does decide to switch, the decision itself is indeed It is commendable, courageous and motivating.

If the business is very important (like Talabat, Foodpanda, or user-critical applications involving heavy daily usage, payments, security, multi-vendor systems, etc.), then from a business perspective, the ideal thing to do is to slowly roll it out in a hybrid fashion Migrate the application. Again, this may not be feasible for everyone, and it may be better to rewrite. It all depends on the structure of the company and business and the strength of the decisions.

It is ideal for project-based companies to start new projects using Flutter (because they have passionate, growing teams and are committed to incorporating new technologies). When they build new projects using Flutter, if Deliver faster and more efficiently than before, and they will automatically expand their business.

For developers and technical teams, any new technology is amazing, but if you are an engineer working in a well-structured, stable company, you should also understand the company’s business perspective to understand their transformation Using new technology perspectives.

If you are a senior engineer/senior engineer, you should convey your enthusiasm to the business department in a language that is easier for them to understand. For pitching Flutter, it can be less time, less cost, less effort, and more Fast delivery, one team, one codebase, less PR reviews, etc. (if you’re a Flutter person, you already know all this).

Business units have to consider multiple aspects when making decisions, so as an engineer, tell them something that will make their decision easier.

The above are my personal views and opinions. If you have different opinions or experiences, please feel free to share them with me in the comments. I will be happy to participate in the discussion of this issue.