Lessons Learned on Managing Technical Debt at Parkmobile

Slides for the talk I gave on Appdevcon at March 15, 2019.

Transcript

1. LESSONS LEARNED ON MANAGING TECHNICAL DEBT AT PARKMOBILE Emre Kucukayvaz
2. Emre Kucukayvaz @emrekyv
4. 1 TECHNICAL DEBT, REVISITED Back to basics. 2 HOW DID WE END UP HERE? “Well, how hard can it be?” 3 WHAT WORKED FOR US? Technically and culturally
6. Technical Debt
8. 1. TECHNICAL DEBT, REVISITED Back to basics.
10. Ward Cunningham
11. “If we failed to make our program align with what we then understood to be the proper way to think about our financial objects, then we were going to continue to stumble on that disagreement which is like paying interest on a loan.”
13. 1. Deliberate
14. 1. Deliberate 2. Accidental/outdated design
15. 1. Deliberate 2. Accidental/outdated design 3. Rotten
16. 2. HOW DID WE END UP HERE? “Well, how hard can it be?”
18. - Similar features, different UX
19. - Similar features, different UX - Swift + Objective-C
20. - Similar features, different UX - Swift + Objective-C - No code sharing, living in 2 separate repos
21. - Similar features, different UX - Swift + Objective-C - No code sharing, living in 2 separate repos + Some modularisation
22. “How can we build a feature once, and use it everywhere?”
23. “How can we build a feature once, and use it everywhere?” * with some customization of course.
24. “How can we build a feature once, and use it everywhere?” * with some customization of course. * we need to differentiate design.
25. “How can we build a feature once, and use it everywhere?” * with some customization of course. * we need to differentiate design. * UX should stay the same if you’re refactoring.
26. 3. WHAT WORKED FOR US? Technically and culturally
27. 1. 
 Decide early: rewrite or refactor?
28. “Gradual rewrite in Swift” - Decouple and isolate the old thing - Replace it with the new thing - Test the hell out of it - Repeat
29. 2. Make (changing) things easier for your team.
30. 8 internal frameworks Each refactoring created > 3 pull requests
31. 8 internal frameworks Each refactoring created > 3 pull requests (╯°□°）╯︵ ┻━┻)
32. Monorepo One workspace + Every change is one PR + Keep the pace
33. 3. Using Swift from Objective-C is horrible, don’t waste your time on it.
34. 4. Decouple aggressively, especially your global dependencies.
35. Keychain UserDefaults Networking Cache Reachability Core Data Date Device Bundle Locale
36. 5. Start from your view controllers and views.
40. Test on production
41. 6. Do not rush to introduce new things.
42. Try to solve actual technical problems, do not try to adapt architectures or techniques because they’re cool.
43. Try to solve actual technical problems, do not try to adapt architectures or techniques because they’re cool. Architectural Decision Records (ADRs)
44. 7. Reduce Work-in-Progress (WIP) and aggressively eliminate dependencies for your team.
47. 1. Decide early: rewrite or refactor? 2. Make (changing) things easier for your team. 3. Using Swift from Objective-C is horrible, don’t waste your time on it. 4. Decouple aggressively, especially your global dependencies. 5. Start from your view controllers and views. 6. Do not rush to introduce new things. 7. Reduce Work-in-Progress (WIP) and aggressively eliminate dependencies for your team.
48. Trust your team, give ownership and celebrate.
49. Emre Kucukayvaz @emrekyv