Scaling Mobile Engineering

Growing your mobile engineering team sustainably while also delivering quality features in your product is a difficult challenge. Adding more engineers onto a project does introduce new problems. How do your development, testing and delivery processes evolve as a team grows? Deniz Veli will share advice and lessons learnt from working on small, medium and large scale mobile engineering teams, including scaling the mobile teams at Etsy and iflix.

Transcript

1. Scaling Mobile Engineering Deniz Veli denizmveli@gmail.com @denizmveli
2. What do I know? Worked on small and large apps teams • Platforms Lead at iflix, Melbourne • Mobile Engineering Manager at Etsy, NY • Android Freelancer, Melbourne • Personal apps
3. Etsy
4. iflix (we’re hiring)
5. Growth. People. Teams. Development. Testing. Delivery.
6. Growth. People. Teams. Development. Testing. Delivery.
7. Growth Why do teams grow? • Build more features faster • Expand into new markets • Integrate/partner - Google, Apple, Facebook, Twitter etc • As a result you need more help with management, tooling, testing, delivery and general process stuff • So you hire more...
8. Growth. People. Teams. Development. Testing. Delivery.
9. People • Hiring - it’s hard ◦ try to mix your skill levels ◦ junior, mid-level & senior ◦ provide mentoring opportunities ◦ consider diversity not just in experience ◦ gender, race, background, age ◦ diverse teams consider more perspectives ◦ your users aren’t all the same • Can’t hire fast enough? Training can complement hiring
10. Teams Web iOS Android Backend Shared feature / project knowledge Platform Teams
11. Teams Feature A Feature B Feature C Feature Teams / Cross-functional Feature D Cross team platform groups
12. Growth. People. Teams. Development. Testing. Delivery.
13. Development App development platform - which will scale? • Webviews? • Hybrid? • Native?
14. Development If you’re growing, aiming for millions of users and great ratings, go native. Hybrid Best of both worlds or best of neither? Still not fast enough give a full native like experience. Usable in parts but not core app flow (want to get featured?) Webviews Fast to get started across platforms, slower for users. Consistent for the product, inconsistent with the platform standards. Not recommended by Google / Apple (want to get featured?) Native Slower to build initially but optimum experience for users in the end. Consistent with platform expectations. Easy hardware integration Recommended by Google / Apple
15. Development Invest in your apps architecture • Front end architecture (MVP, MVVM, VIPER, etc) • Define your app architecture • Build for testability ◦ dependency injection ◦ separation of concerns • Build components where you foresee re-use • Code reviews / pairing is essential
16. Development How do you speed up development on multiple native platforms? Make your apps dumb! Offload logic to the server in you API’s. • Basic ◦ data storage ◦ business logic • Advanced ◦ server driven layout ◦ configuration and feature toggles
18. Development More on feature toggles… • Switching functionality in your app based on a flag - ideally updated remotely if (featureIsEnabled("show-new-redesign")) { showNewRedesign(); } else { showOldDesign(); } • Enable continuous delivery and A/B testing • Services - Firebase Remote Config, LaunchDarkly + more • Cleanup overhead • Reading - https://martinfowler.com/articles/feature-toggles.html
19. Growth. People. Teams. Development. Testing. Delivery.
20. Testing • Testing pyramid • Lots of unit tests • Some integration tests • Fewer manual and end-to-end tests • Private internal staff testing • Public beta release groups
21. Growth. People. Teams Development. Testing. Delivery.
22. Delivery Feature based delivery • More people = more code. • If you don’t release regularly = big releases ◦ mammoth testing cycles and increased risk ◦ developers are further from the changes made ◦ increased mean time to recovery on incidents ◦ users go without fixes and improvements
23. Delivery Continuous Delivery - unused code doesn’t teach you a thing • Release train = “bug fixes and performance improvements” • Ship to the app store every 1 - 4 weeks • Feature toggles = big goals, small steps
24. Delivery Monitoring • Crash reporting • Error logging • App analytics and tracking • Performance monitoring • Respond to customer feedback
25. Easy enough?
26. Hard parts • Losing control & letting go • Perfectionists vs pragmatists • Big changes in the code & app take time • How big is too big? When does more = less?
27. Where do you start? You’re growing but don’t know where to start? • Start thinking server driven and API first • Deliver your apps regularly to users • Setup basic feature toggles so you can keep shipping
28. Questions? Deniz Veli denizmveli@gmail.com @denizmveli