Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Mobile Product Engineering

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.

37fbf83b7d45711e41e774e29fed710e?s=128

Arnav Gupta

June 09, 2022
Tweet

More Decks by Arnav Gupta

Other Decks in Programming

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