There are two teams that do not know each other’s characters at all, do not have common interests and do not communicate at lunches and smoke breaks. How long will it take for them to work together? A similar example: if you had financial problems, who would quickly enter your position – the first person you meet or relatives and closest friends?
Good communication between departments is due to the ability at any time to walk several meters from one office to another and discuss the problem in person. Our team was deprived of this opportunity on one of the projects where a developer from Europe was responsible for the backend. The five-hour time difference put everyone in a difficult situation: the back-end developer only got in touch in the early morning, and if our team could not hold a rally, then we had to either postpone it a few days in advance, or cancel our affairs. Total: instead of walking to the office next door – correspondence in chats, chaotic calls, more detailed preparation for meetings and other reasons that stretched communication and postponed the release of the first version of the application for several months.
While our team eliminates the consequences of such events, clients calculate losses – both financial and reputational. Here are some more memorable cases:
One of the apps has a button to unsubscribe. Third-party backend developers decided to change the interface of the unsubscribe method, but they did not inform us.
The work of the client and server was out of sync, so letters continued to come to users. The button didn’t work for 3 months, which led to angry reviews from users and a blow to the company’s image.
Users could not make an order through the application to an address that included the “/” sign. For the server to stop considering them invalid, the backend command needed to insert this character into a regular expression in the code that checks addresses. A week passed between the discovery of the problem and its solution – enough to lose a certain number of users.
We had a choice: to make edits in the application on our own or wait for literally one manipulation from the server developers. When it was impossible to wait any longer, we took action, but the financial costs are unpleasantly impressive: payment for the work of iOS and Android developers, complete regression, testing, release – the client pays for all this.
When teams work on the same side, they find a solution without stress, arguments, and the need to earn credibility in each other’s eyes. At the same time, managers have leverage that they lack when the team is remote. All this will speed up the pace of work on your project.
In situations where the back-end developer delays with the result, but it is necessary to show the work of the product, we can create a mock server. This is an imitation of requests from the application and responses from the server through json objects hardwired into a mobile application. The structure of such objects is based on what is written in the documentation compiled by the analyst. The method helps out when developing MVP and when developing an application and backend in parallel, but it is important to know that time is spent writing code that will become useless when the server is up and running. Therefore, in order not to stretch the budget, we suggest that the client freeze the development of the functionality tied to the backend and take on another task.
Up-to-date documentation
Integration of a mobile application with a ready-made third-party service is a typical development story: it is not profitable to write payment services and chats for one application from scratch. Like any others, these services and their APIs are being developed and updated, which should be reflected in the documentation that is available on the official website of the service.
But what if the developers of the service don’t do it in a timely manner? Then our team will configure the integration using outdated documentation, and the application will not understand in what language the service communicates with it. The support service is available only to those who paid for the account, but let’s imagine that it is not paid. As a result, the developer is helplessly making assumptions, googling forums and spending more time on the task than he could. And along with time, he spends your money.
The same difficulties can be experienced by mobile studio developers when they integrate with a backend made on the side. Outdated documentation is the result of the human factor: not all changes are made in a timely manner. Any embarrassment associated with this, the teams on one side, solve the dialogue. But if you want to transfer a project developed by us for the support of another studio, then you can be sure: you will receive documentation that an innovator can understand.