Mobile Product Engineering

A talk I gave at SaaS Engineering (https://www.youtube.com/channel/UCPNcEyOQD2-X2YB6akbr-xA) on how to build a better mobile product engineering team.

Transcript

1. Mobile Product Engineering Arnav Gupta
2. Disclaimer: Personal Bias Past experiences which form my opinion • 1.5 yrs : Platform Team Lead & Mobile Engineering Lead @ Zomato • 1.5 yrs : Lead Engineer (Android) @ Target • 10+ years mostly native Android Advice most suited to • Scaleups / Large tech teams • Ecom, B2C, large DAU (1M+) products
3. Outline Engineering Org Design Process Testability*
4. Engineering ‘scale’ is different modularisation 3rd party libraries navigation, deeplinks, state
5. ‘scale’ is different • device, OS, version fragmentation • low bandwidth, low storage size, low RAM devices ◦ content consumption apps: frequent customer complaints = data usage ◦ in a competitive field: app size ∝ uninstall rate • txns/day or API hits per sec are STILL important; why ? ◦ good caching on frontend, helps backend teams ◦ lots of ‘scale’ mitigation happens on frontend (eg: exponential backoff) ◦ frontend can DDoS backend
6. modularisation
7. 3rd party libraries • 1 line of code you don’t own = 1 line of risk you undertake • even the biggies can fail you ◦ Google Maps SDK bug: 20M+ users, 96% of top 1000 apps affected ◦ Facebook Login SDK bug: 10M+ users, 80% of top 1000 apps affected • include prebuilt vs add as source ◦ build-time hit vs ability to self-fix ◦ security considerations ◦ CI able to pull 3rd party libs
8. deeplinks, navigation, state • the closer your navigation graph is to a pure state machine the better you’ll sleep at night • deeplinks should be idempotent, like GET requests, and just work™ zoma.to/r/135 https://zomato.com/restaurants/ncr/gulati zoma.to/u/34 fb://user/arnav https://facebook.com/@arnav
9. deeplinks, navigation, state
10. Org Design to QA or not to QA pod-wise teams platform team?
11. to QA or not to QA “ We can solve any problem by introducing an extra level of indirection ” - David J Wheeler to Butler Lampson
12. to QA or not to QA “ We can solve any problem by introducing an extra level of indirection… … except the problem of too many levels of indirection ”
13. to QA or not to QA • PMs do have ability to toggle flags on DB, install apps, capture logs • PMs will do “strategy”, cannot spend time on run-of-the-mill testing and operational tasks • Engineers do not test thoroughly, we need a QA to be bulletproof • Testing features need co-ordinating between frontend + mobile + backend engineers, QA can coordinate with all of them better • We have compliance reasons • Why do other companies have QA teams then?
14. pod-wise teams start when > 5 team size OK if 1 pod = 1 person 1 pod owns 2 modules ✅ 2 pods work on 1 module ❌ split pods per business domain ✅ split pods per tech function ❌
15. platform team ? do you need one? platform teams clean up after feature pods ❌ platform teams built libs that feature teams use ✅ platform teams are responsible for reliability/performance ❌ platform teams create tools + monitoring for better app perf ✅ platform teams do releases ❌ platform teams own CI/CD infra ✅
16. Process trunk-based development release train build versioning 1 ticket = 1 branch = 1 build = 1 signoff
17. trunk-based development & release train
18. trunk-based development & release train
19. trunk-based development & release train
20. build versioning • what is the APK version of the following apps you use on your phone ? ◦ Google Maps ◦ Google Pay / PhonePe / PayTM ◦ Swiggy / Zomato • product features ↔ version number pairing not needed • 2022.12 (week num), or 2022.5.1-5472 (YMD+buildnum) • v10 of Android = v10 of iOS has same features - why ? • control feature rollout via ◦ server side feature flags ◦ API headers
21. 1 ticket = 1 branch = 1 build = 1 signoff • 1 short-lived branch created for 1 JIRA ticket ◦ scope your work so that this is < 1 week of work • Use Firebase Test Labs + Test Flight for CD-to-employees • PM/Design/Business should be able to “install a ticket id” • Single place to for all stakeholders to - ◦ get build for the ticket ◦ discuss design / specs / requirements ◦ sign off on release
22. Testability unit test vs integration test snapshot tests? debug drawer & feature flags enabling manual testing
23. unit tests vs integration tests • tooling, difficulty and build time of integration tests • what are you testing ? ◦ input/output of function? ◦ business logic? ◦ state machine? • mocking vs faking ◦ can we test by hitting real APIs ?
24. snapshot testing do you need it ? fragility & flakiness keeping up with design iteration speed accessibility tests
25. debug drawer & feature flags • API server domain switching • A/B test (assuming test/control group) • Assume user id • Feature flag local overrides • Dev Tool enable/disable ◦ profiling ◦ mem-leak catching ◦ event / logs / trace capturing
26. enabling manual testing
27. enabling manual testing
28. good reads
29. blogs developer.squareup.com eng.uber.com/category/articles/mobile slack.engineering zomato.com/blog/category/technology blog.hotstar.com/tagged/engineering