Scaling mobile dev teams
2 likes713 views
This document discusses patterns for scaling mobile teams using Android examples. It covers organizing teams by product vs technology, adopting patterns for consistent development practices, testing strategies like unit testing, behavior testing and contract testing, and selecting technologies like native vs hybrid development. The goal is to build predictability, speed up feedback loops, and allow teams to continuously deliver features at scale.
Scaling mobile dev teams
- 1. Patterns to scale mobile teams Using examples for Android Priyank Gupta Sahaj Software Solutions Pvt. Ltd.
- 2. Mobile is eating the world
- 3. Evolution in last 5 years Mobile Inclusive Mobile First Mobile Only
- 4. 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
- 5. Worldwide market-share Smartphone market share - Report Android iOS Others 83% 14% 03%
- 6. 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.
- 7. Why mobile is different?
- 8. 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
- 9. Survival for fittest Ideas Tons of ideas see daylight in an healthy ecosystem Saturation Redundant businesses cause saturation to occur Consolidation Consolidation in form of acquisition, mergers and natural death. Healthy co-existence Winning teams are lean, agile, ahead of competition and know how to scale.
- 11. Things that matter Hiring & People Team organization Technology selection Development practices Scalable design Testing & Safety nets Release cycle & practices
- 13. In business of delivering experience HTML5 Native Custom Bridges Cordova HTML5+ Service workers React Native Xamarin Selecting mobile implementation strategy Experience + 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
- 14. Organizing teams for scale
- 15. 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.
- 16. .. 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
- 17. 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.
- 18. 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
- 20. 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
- 21. 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.
- 22. 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
- 23. 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)
- 24. 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
- 25. 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
- 26. 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 one toggled off Feature two toggled off Feature two toggled on Feature one toggled on
- 27. 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
- 28. Building reliable safety nets
- 29. 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
- 30. 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
- 31. 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
- 32. 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
- 33. Testing the service contract Actual Service/APIs Contract 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
- 34. 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 iOS Orchestrator
- 35. Thanks for pulling through! priyaaank