scaling mobile dev teams

Patterns to scale mobile teamsUsing examples for Android

Priyank GuptaSahaj Software Solutions Pvt. Ltd.

Mobile is eating the world

Evolution in last 5 years

Mobile Inclusive Mobile First Mobile Only

Building it for 3.2 billion people

7.1 Billion - World population

7.9 Billion mobile devices

3.2 Billion Internet Users

State of connectivity 2015 - Report

Mobile users are the internet users

Worldwide market-share

Smartphone market share - Report

Android

iOS

Others

83%14%03%

Everything in ‘context’

Discovery

DeliveryMedia

Payments

Aggregation

Discovering content, deals, products, places and information happens based on location, context and conversations..

Payments, wallets, money transfers and currency conversions happens via mobile apps instantaneously.

News doesn’t come from media houses. News is crowd sourced, crowd curated and pushed real-time to consumers on mobile.

Delivery is done across diverse products and services; ordered, scheduled and tracked via mobile real-time.

Services are aggregated and made available on mobile across all domains. Delivery, taxis, food, handy-work etc.

Why mobile is different?

Challenges

Multiple platforms and

form types

No control on environment /

device

Work across version and device types

Design with usability at center. Stay

ahead of competing feature set

Forced SDK update and

different runtimes

Dalvik, ART, Arm6, Arm7

Survival for fittest

IdeasTons of ideas see daylight in an healthy ecosystem

SaturationRedundant businesses cause saturation to occur

ConsolidationConsolidation in form of acquisition, mergers and natural death.

Healthy co-existenceWinning teams are lean, agile, ahead of competition and know how to scale.

What affects scalability

Things that matter

Hiring & People

Team organization

Technology selection

Development practices

Scalable design

Testing & Safety nets

Release cycle & practices

Technology selection

In business of delivering experience

HTML5

Native

Custom Bridges

Cordova

HTML5+Service workers

React Native

Xamarin

Selecting mobile implementation strategyExperience + Reach

Cost

Laser

Cover your bases

Long term strategy should focus on building a native experience. The journey can be gradual or with a jump start.

No adoption

No magic bullets

Organizing teams for scale

Technology teams vs..

Release 1 - Mix of feature X & Y

Android

iOS

Services

Siloed by technology/platform

If feature parity is important then lowest denominator goes into release

Missed opportunity to optimize services based on common domain across platform

Easier to draw boundaries.

Initial velocity gain due to technical know how.

.. Product team

Release 1 - Feature X

Release 1 - Feature Y

Services iOS Android

Initial velocity impact

Shared understanding of product as a

whole

Feature parity

maintained in releases

Can get away with a leaner

team. Problems

solved once.

Service design can have

considerations for clients

baked in right from start

Handovers & feedback loops

Development

Design

Testing

Story started

Story done

Quicker feedback loops keeps the cost of change low and validates the shared understanding constantly.

Services are part of product

Services

App

Own services as first class

deliverable

Use patterns to decouple

legacy services

Leverage REST Level-3

characteristics to make service

adaptive

Use patterns to optimize services

for target consumer platform

Scaleable dev practices

Predictability & Consistency

Where would you find the code to fetch details from database?

Can you predict how someone on team would fetch images in background?

Will everyone know how to find the service call you wrote?

Can everyone on team predict what’s going to be covered in an espresso test?

Do you know where to find the styling for a specific UI element?

Using conventions you can build predictability on team to simplify mental models needed to understand the codebase

Define the simple machines

Screw Wheel & Axle Pulley Lever

A simple machine can hammer in the basic principle and allow far more complex machines to be developed with coherence.

Adopting patterns

Persistence / db

Web ServicesUI / Styles Debugging

Invest time in first of everything. Build a team-wide definition and reuse the pattern to promote consistency and predictability.

Background tasks / Services

Device hardware

Web service patterns

for consistent service calls across features. Retrofit + Singletons + Observers

Callback implementation for Retrofit API (Singleton)

Retrofit service interface

Observers

Activities, fragments or services

Data retrieved from service (possibly cached)

External integrations patterns

BFF approach | Adaptive API

Adaptive API

Backend for frontend

Downstream systems

Adaptive proxy APIs

Consumer centric abstractions - BFFs

for optimal experience of services on devicesAdaptive APIs BFFsor

for consistent execution of short async tasksAsync task wrapper + Observers Thread (Pools)or

Asynchronous tasks patterns

Obtain instance

Set data

Fire task

Check references

Call observers

Die or loop

Main thread

Spawned/Pooled thread

Scaling commits with patterns

Feature one

Feature two

Master

Feature toggles explained

vs

Requires complex CI setup to constantly identify and merge branches and test state at any point of time.

Requires building a feature toggle functionality with dynamic toggles and tests to validate all feasible path.

Master

Feature onetoggled off

Feature twotoggled off Feature two

toggled on

Feature onetoggled on

Debugging and logging patterns

Force upgrade Debug console Thread local logging

Crashlytics

Build consistent set of practices to debug issues using Debug console Crashlytics Thread logging

Building reliable safety nets

TDD - Achieving 80-85% coverage

1

2

3

4

5

6

With domain logic extraction

Dependency injection with constructors

Mock objects using mockito

Powermock + Mockito for static classes **

Countdown latches & listeners for threads

Presenter pattern to extract view logic

Building the most comprehensive set of tests at unit level

Behavior tests with page object pattern

pattern comes in handy to modularize behavior tests and mimic flow relationshipsPage Object

Home screen

Product listing

Notifications

Orders

Execution context

Asserting app behavior

Service Stubs

Real Service

APIs

can be used to address the coverage gap left by unit tests in AndroidEspresso

WireMock Mountebank Stubby

Making behavior tests effective

Turn on ‘don't keep activities in

background’

Among all others, run the

smallest supported

emulator with software keyboard

Immediate app

distribution to alpha. Hallway testing

Multiple emulators in cloud or via

Docker images across CI agents

Keep behavior tests lean, quick and focused on happy path

Testing the service contract

Actual Service/APIsContract

Tests

Service Stubs

Contract tests run typically few times a day. A stub replaces remote service for behavior tests to keep tests responsive, stable and predictable.

Every commit

Periodically

Testing cross app flows

is a great starting place to orchestrate tests across apps

Uber engineering blog

Octopus by Uber

Consumer app

Warehouse app

Consumer on iOSOrchestrator

Thanks for pulling through!

priyaaank