Selling Kotlin to Management

How can we as Android developers sell Kotlin to management and the stakeholders? Why would we want to?

Transcript

1. Selling Kotlin to Management Yes we can!
2. I did say managers, and you probably came here for that
3. I lied
4. It's truly about the stakeholders
7. It's truly about the stakeholders • You
8. It's truly about the stakeholders • You • Colleagues
9. It's truly about the stakeholders • You • Colleagues • Management and business
10. You??? Maybe you aren't truly convinced
11. Why is Kotlin right for me?
12. It's official
13. Null safety
14. Immutability
15. Code size reduction
16. I still was not convinced
17. Groovy Broke My ❤
18. Kotlin looked weird.
19. We started using GraphQL, everything was nullable
20. I had no desire for crazy nested if statements.
22. Kotlin saved me
24. There's fun stuff too! val disposable = programStore.get(key) compositeDisposable += disposable Using extensions! operator fun CompositeDisposable.plusAssign(disposable: Disposable) { this.add(disposable) }
25. That's my story, on to convincing colleagues
26. Maybe teammates are nervous or don't have the time to learn something new
27. It's all about discussion and dialogue
28. what you can do
29. what you can do • Try sending out daily resources (articles on operators, tips, and best practices)
30. what you can do • Try sending out daily resources (articles on operators, tips, and best practices) • Examples of Kotlin conversions
31. what you can do • Try sending out daily resources (articles on operators, tips, and best practices) • Examples of Kotlin conversions • Plan for in office working sessions to demonstrate or dev arch meetings (kotlin koans)
32. talking points
33. talking points • Best strategy by far for me has been discussion of what people think won't work; they usually bring up
34. talking points • Best strategy by far for me has been discussion of what people think won't work; they usually bring up • Don't want to switch entirely to Kotlin (counter with interop)
35. talking points • Best strategy by far for me has been discussion of what people think won't work; they usually bring up • Don't want to switch entirely to Kotlin (counter with interop) • Is there that much of a point (counter with shorter code/ nullability)
36. talking points • Best strategy by far for me has been discussion of what people think won't work; they usually bring up • Don't want to switch entirely to Kotlin (counter with interop) • Is there that much of a point (counter with shorter code/ nullability) • support, libraries, tooling (counter with all these work)
37. Official Google samples are now written in Kotlin Conference slides in Kotlin
38. Follow your leaders! Android luminaries are writing articles and code in kotlin today
39. On to convincing the suits!
40. Officially supported by Google What does this mean?, tooling works, bugs directly to Google
41. Jetbrains support
42. Copy paste in editor
43. Disassemble and examine bytecode
44. Proper test support @Test fun getConstraintSet() { CardConstraint.values().forEach { val card = mock(ArticleCard::class.java) Mockito.`when`(card.cardType()).thenReturn(it.cardType) Mockito.`when`(card.rendition()).thenReturn(it.rendition) if (it.columnCount > 0) { assertMatching(card, it, it.columnCount) } else { for (columnCount in 1..4) { assertMatching(card, it, columnCount) } } } }
45. Works with Data Binding! override fun bind(binding: CardArticleBinding, position: Int) { ConstraintSet().apply { load(binding.root.context, constraintSetLayoutRes) applyTo(binding.root as ConstraintLayout) } binding.root.post { binding.card = card } }
46. Latest Android and Gradle tools, incremental and instant compilation
47. Lastly, It just works with everything; Picasso, RxJava, Guava, Dagger etc....
48. Managers don't care about any of that they care about ROI (return on investment)
49. ROI
50. ROI • Reduced issues overall (type safety forces safer code)
51. ROI • Reduced issues overall (type safety forces safer code) • Reduced time spent fixing production issues (less bugs, see above)
52. ROI • Reduced issues overall (type safety forces safer code) • Reduced time spent fixing production issues (less bugs, see above) • Reduced time on boilerplate code (less code to write)
53. ROI • Reduced issues overall (type safety forces safer code) • Reduced time spent fixing production issues (less bugs, see above) • Reduced time on boilerplate code (less code to write) • Reduced code review time (less code to review)
54. Leads to: Increased feature development & Happier Developers
55. Kotlin != Golden Hammer Good managers want to know the bad as well
56. The cons
57. The cons • Limited static analyzers
58. The cons • Limited static analyzers • Minor increase in build time
59. The cons • Limited static analyzers • Minor increase in build time • Mockito needs some tweaking (when, open keyword)
60. How to get your feet wet low risk
61. How to get your feet wet low risk • Unit tests, not in source (we wrote kotlin tests that called java classes)
62. How to get your feet wet low risk • Unit tests, not in source (we wrote kotlin tests that called java classes) • Annotation processor rework or impl (apollo uses kotlin to generate java for graphql)
63. How to get your feet wet low risk • Unit tests, not in source (we wrote kotlin tests that called java classes) • Annotation processor rework or impl (apollo uses kotlin to generate java for graphql) • Put behind interfaces to hide implementation
64. How to get your feet wet low risk • Unit tests, not in source (we wrote kotlin tests that called java classes) • Annotation processor rework or impl (apollo uses kotlin to generate java for graphql) • Put behind interfaces to hide implementation • Know that mistakes will be made as everyone learns it
65. Links and resources Kotlin weekly (www.kotlinweekly.net) Kotlin koans (kotlinlang.org/docs/tutorials/koans.html) Kotlin by Example (hadihariri.com/2017/06/12/kotlin-by-example) Intro to Kotlin Google IO 2017 (youtube.com/watch? v=X1RVYt2QKQE)