Original address: medium.com/snapp-mobil…

Author: Medium.com/@jasperamor…

Published: November 5, 2019-4 minutes to read

It’s been a while since I started a new development team from scratch. However, I recently started working on Snapp’s Flutter team. In this article, I explained how I got Flutter to take root and thrive in a brand new team.

Photograph: Nik MacMillan on Unsplash.

Building a Flutter team in 2019 has some challenges.

  • Flutter is new, and while its reputation is growing, it is not well established. Building a Flutter team means that you and your colleagues are betting on a new technology.

  • It’s hard to find people with significant experience with Flutter, i.e. multiple real-time projects running for a period of time. You will most likely build a team without the experienced Flutter leadership.

  • The architecture and practices developed by Flutter are emerging. It is difficult to evaluate various approaches at this stage. This makes it harder to establish preferred practices and can mean that the initial project may take a completely different approach to architecture.

  • You have to make sure that you can create a steady flow of good projects for your team. Idle teams don’t tend to stay together for very long. They need technical challenges, they need to build real-world products and, most importantly, get them into the hands of users.

Given these challenges, how do we build our Flutter team?

Drill the

In our projects, we typically see many aspects of a mobile application. We are putting these together into a game manual that can be used as a reference for the team building the Flutter application.

This script references articles, packages on pub.dev, code we’ve already written, and the Flutter documentation. Our goal is not to create a single architecture, but to map the existing knowledge and methods of Flutter so that we can get to the subject as quickly as possible. In the end we will probably determine the preferred course of action and the Flutter community will do the same.

What will go into the game manual? Topics such as dealing with different layouts (vertical vs. landscape, mobile vs. table), integrating push notifications, local storage, application phases, API integration, multi-platform building, modularizing applications, CI, testing, etc.

Focus and Expertise

To make the team effective as quickly as possible, we decided to adopt a divide-and-conquer strategy. This means that we have created three knowledge tracks.

  • Layout & UI – Topics related to building an application’s user interface, including managing multiple layouts, platform changes, animations, and user interactions.

  • Data and API management – call apis in different scenarios (e.g. REST and GRPC, streaming data, etc.), manage data in the application (e.g. Bloc, Provider, etc.), integrate with UI.

  • Cross-domain topics – This is our “others” bucket for CI, writing plug-ins, working with deep links, push notifications, and so on.

Our approach is to have each member of the team focus on one track at a time as a specialty. Once we feel we know enough about the current orbit, we rotate the orbit.

preaching

At Snapp, we have a lot of passion and strong opinions about technology. This creates some healthy, friendly debates about the technology we use. As a team advocating for new technologies, we have not had a long track record of success, which means we have to be evangelists.

Communicators are positive to a team. When done in a constructive way, it encourages teams to dig deeper into a technique in order to explain it to others. For our team, this also meant that we had to understand Flutter in the context and in contrast to other technologies. Again, it helps to broaden the knowledge.

fun

As a team, happiness is always healthy. And by “fun,” I don’t mean horsing around the office or playing ping-pong.

By this I mean geek fun. Specifically, we do things like throw out small coding challenges or technical problems to others on the team. When done in an open and friendly manner, we find that we can learn a lot. It also helps create a team culture where we can make mistakes (i.e., get things wrong) and trust others to help us when we don’t know what.

Warning – I’ve also seen this happen in a toxic way, with team members using it to try to make themselves look smart at the expense of others. Don’t do this

For example, one of the Dart language challenges recently presented by colleagues is to extract all the words from a sentence, which are palindromes.

The experiment

On client projects, it’s hard to push boundaries. An unknown framework or unproven approach can bring unnecessary risk to the project. (It’s fair to say that the use of Flutter itself was a bit of an experiment in 2019).

So we used a simple project as a playground for experimentation. For example, I’m interested in how a Flux-based architecture might work with Flutter. A lab project is the best place to try this out.

We chose two experimental projects from the Flutter team. One is a simple ToDo application — yes, not very primitive. The second is an app originally built by Juhani Lehtimaki for learning the Cyrillic alphabet. Try the Android version of the Play Store).

TL; DR

How do you build a team around a relatively new technology that doesn’t have a strong track record and emerging patterns and frameworks? This is the challenge for anyone who builds team Flutter in 2019. In this article, we describe some of the ways we are going to build the Flutter team and address the challenges that come with it.

Translate via www.DeepL.com/Translator (free version)