Client reports that bugs on one mobile platform do not correspond to bugs on the other, and there are discrepancies in user experience which cannot be explained solely by differences between the platforms.
I asked whether bug fixes propagated properly between the platforms, and the answer was “sometimes”. Next I requested an org chart, which revealed the problem. (My followup would have been to examine the code repository’s history, but that wasn’t necessary in this case.)
A capable offshore developer had been hired to manage the iOS implementation. Later, a capable offshore developer was hired to manage the Android implementation. Both of these individuals were talented in their work.
Unfortunately, neither of these individuals was senior to the other. A well-intention plan (to recruit capable independent people) backfired. Each respected the authority of the other, and neither was “in charge”.
At my client’s company, the CTO was not a programmer, and therefore gave no direct code-level oversight. The iOS dev hired and managed a small team, and so did the Android dev. They were good enough at their work that they kept closely synchronized for over a year.
However, their codebases were utterly divergent. This created inefficiencies because there was platform-independent code relating to business logic, which was needlessly duplicated for each platform. In essence, the company had hired two unrelated dev teams to create two unrelated apps which simply looked alike. As the product grew in complexity, the devs were eventually unable to keep the platforms in sync.
The remedy was to create an initiative whereby both teams would pause their work, identify aspects of the codebase which could be merged, and commit to a single leader for managing that central codebase.
The company’s CEO and CTO held a joint meeting with both dev leaders, and their full teams, in order to be completely clear about the directives. They explained that both leaders were deemed equal in ability, but that final authority would rest with the leader who had been hired first.
This uncomfortable situation could have been avoided by a more hands-on CTO; the two remote teams had been given too much autonomy. Fortunately, the company was in the process of planning and scheduling a major new release, so the cost of refactoring was built into the larger budget and timeline.