Saving on mobile cross-platform development: Skyeng case

Hi, I'm Andrei Kucherenko, Skyeng mobile development team. We make mobile applications for iOS and Android. They have the same functionality and the same interface up to the style. But because of the different platforms, the development of a single application seems to be quite expensive. In search of opportunities to save on mobile cross-platform development, we tried four solutions:

• Combining iOS and Android developers into one team
• Creating working groups to solve complex problems
• Savings on recordkeeping
• Writing common code

I had the opportunity to make several reports on what came of it; In this article I collected the main observations and results.

Combining iOS and Android developers into one team

Two years ago, we had two separate mobile applications and two development teams connected only by a general product manager. A lot of problems arose from this: the applications of each other externally resembled only remotely, they worked in many different ways, the developers had no idea how the neighboring application worked, and regularly bugged all sorts of bugs and errors in logic. At a certain point, it became clear that it was impossible to continue this way, and the first thing we did in this connection was to unite the developers of iOS and Android into one product team, making a number of processes common.

One of these processes was a technical review.

Before getting to the developer, the task goes a certain way. For a start, it is formulated in the User Story format, sketches or layouts are drawn on it, and then an epic is created, which describes the user problem and its solution. In this form, the story gets to the team leads, if it is a cross-command epic, or to one team lead, if it is for one team. There, everything is decomposed to the level of individual tasks. In each such task, if it is appropriate, a possible solution is described, tasks inside Epic are linked with each other, various blockers are put down, which removes a lot of unnecessary communications. After this, a technical review takes place directly on which the final decision will be recorded and the estimate will be set. Also at this stage, the task can be further decomposed, if the estimate is more than two days.

How we save on a joint technical review:

• in most cases, we get the same technical solution for iOS and Android. Different solutions are also possible, this may be due to the different architecture of the platforms, but in the context of the problem, the difference is often minimal;
• synchronized architecture and structure of the two applications. This eliminates the situation when the product comes with another feature, and we estimate the iOS task at two o'clock, and Android - at a week, because there everything will have to be rewritten;
• most often we get well into the assessment. If we have very different estimates for the platforms, this may indicate either that the developers did not understand the task, or some platform problems that need to be addressed;
• With this review, experience is exchanged between iOS and Android developers, and I believe that they should have an idea of ​​how the neighboring platform works. It often turns out that a solution from one platform is successful for another;
• simplified manual testing. Features are implemented on the basis of one technical solution, if the QA finds some bugs, then this is a reason to repeat the same steps on another platform. Most often the same bugs are there;
• universal soldiers capable of writing for both platforms: if they are, they can be switched between projects, which increases the bus factor and makes it easy to transfer vacations and absences. There is no situation when one platform runs far ahead during the holidays.

Bus factor: the number of people in the team, which must bring down the bus, so that the project could not continue.

Working groups to solve complex problems

Very often, to solve the problem, besides directly writing the code, we need to do some research, design, and if the task involves team interaction, spend a lot of time on communication. In the context of mobile development, any tasks that do not require all of this represent something trivial that does not involve work from the backend. I call them "simple", and all others - "complex."

I analyzed the worklogs for the allocation of time spent on writing code, communication, design and research. This is what happens for simple tasks:

Everything is clear here, basically we write the code, the cost of it is up to 80% of the time.

Very often, tasks require some sort of refinement from the backend, which automatically makes it an inter-command. Here, more time is spent on design and communication. The proportion of writing code is reduced:

Often, products come with tasks that do not fit well into the current architecture of the application, and we need to spend time to find a good solution: perhaps, to plan some kind of refactoring, to immediately conduct it as part of the task, etc. In this case, a lot of time is spent on design:

Finally, the tasks with which it is generally not clear how to approach, where you must first investigate and design:

If the work on complex tasks does not coordinate in any way, then all the work not directly related to the writing of the code will be done twice. And in complex tasks it is 50% of the solution time, often more.

I found a way out: I just took and closed all these tasks on myself. I managed to save time, but I became constantly overloaded, I didn’t have enough time to pay attention to low-priority tasks, developers had to wait for me, everything was bad. The problem arose again, and we have already solved it by creating working groups.

The working group is a few iOS and Android developers who will be directly involved in the implementation of this feature. One is appointed as the leader, he will be responsible for the design, research, interaction with other teams. The result of his work will be documentation, where everything is fixed; these docks are then reviewed by the working group and team leader, and the team proceeds with implementation.

As a result, received:

• reduced load on timlid, while he does not lose control over the course of the task. I participate in all key meetings, review the technical solution, actually control the task before it gets directly to the development;
• the developers are very motivated. When we tested this practice, everyone came up and said, "cool, let's try it again." There were no people who would not want to do this and would prefer “just code”. People have more opportunities for development;
• the bus factor has risen, the team has become more independent, plus on such tasks you can clearly see those who need to be further developed into timlids. Solves the problem with the departure of Timlid on vacation.

Document savings

We decided to keep the documentation in Markdown and store it in a githab repository. The documentation is revised along with the code and with the pull-request, so we exclude situations when something is written, but no one read it, and when it is needed, no one understands anything. Documentation with the code allows you to dive into the context, to understand what was a pull-quest.

We edit the documentation directly from IDEshki, most of them are able to render Markdaun, it doesn’t take away from writing code, you don’t have to go somewhere in confluence, the danger is reduced that the developer will simply score to update it. For those who have downloaded the repository locally, we throw links to GitHub, they can also read everything.

Finally, such a docking style helps in onboarding a new developer: together with the code, he gets all the possible code-styles, conventions, instructions for building the application, entering the team is much easier.

Common code

The idea to write a common code is not the newest, there are a lot of tools to do it. We tried C ++ to write a vocabulary training library, and we have a small application written entirely in Kotlin Multiplatform. Theoretically, when using the cross-platform development tool, our expenses on writing code should be halved. But additional ones appear:

• costs at the start. A lot of time will have to spend on it to collect all this, run, test, test hypotheses, train the team. In some cases, these costs are so large that no profit is visible at all;

  
  

• writing a platform code. From my own experience and based on a number of sources I can say that no matter what tool you choose, if you have a fairly complex application, then sooner or later you will have to write the platform code. Time to write it varies greatly depending on the selected tools;

  
  

• elimination of defects. Most of the tools are still pretty raw, they have bugs, you have to run into some kind of backwards-breaking releases, and you have to spend some time on eliminating all this;

  
  

• bypass restrictions. Cross-platform tools can have architectural or some other restrictions that can be resisted and spent time bypassing them. Sometimes these restrictions are so serious that you have to give up the tool altogether. For example, Airbnb abandoned React Native and rolled back to native development;

  
  

• Complication of development. You have to either write code for two platforms at once, which not everyone can do, plus additional communications will appear. The absence of native IDEs also does not simplify such development.

  
  

To compare the costs of those methods of cross-platform development that we tried, identified four main groups:

• starting costs
• expenses for writing common code
• expenses on writing a platform code
• infrastructure costs (something that does not apply to the first three points)

Took worklog and compared the time actually spent on cross-platform development and the time we would have supposedly spent on native development.

Each column is a task. In the case of C ++, it was a fairly easy start, but the infrastructure costs were substantial, the overall savings were only 29%. C ++ was also abandoned because the bus factor lowered this language: our mobile developers do not know C ++, they can maintain the code, but no one in the team had any serious experience.

Very high starting, but so far the cost of the platform code and infrastructure are small. We did not have enough for a good analysis of the number of tasks, 19% saved on the current situation. Assuming that we will do a lot of tasks, and rejecting start-up costs, we will receive savings of about 40%, unless, of course, there are any serious problems in the future. Another plus is that most developers are fairly familiar with Kotlin.

The downside is obvious - the complexity of the processes. We either write for both platforms at once, but not all of them can, or we wait until someone writes a common part, then we wake it up, then it turns out that it doesn’t fit, etc. etc. We have to lay additional costs at the design stage, so that everything must start right away.

Total:

• Save on the processes of mobile development and writing code can and should be. Properly constructed processes help not only to save, but also to solve a number of additional tasks.
• When choosing tools for cross-platform mobile development, you need to carefully assess the risks and real labor costs.