held at CocoaHeads Berlin 04.2018

1. Wind of Change
Maxim Zaks
@iceX33

2. Is change a good thing?

3. Changes as seen by software
developers

4. Changing data representations
{"name":"Maxim", "age": 37}

5. Additive / non destructive change
{"name":"Maxim", "age": 37}
=>
{"name":"Maxim", "age": 37, "city": "Berlin"}

6. Almost non destructive change
{"name":"Maxim", "age": 37}
=>
{"name":"Maxim", "birthday": "XXXX-XX-XX"}

7. Destructive change 1
{"name":"Maxim", "age": 37}
=>
{"firstName":"Maxim", "age": 37}

8. Destructive change 2
{"name":"Maxim", "age": 37}
=>
{"name":{"firstName":"Maxim","lastName":"Zaks"}, "age": 37}

9. Solutions to the problem can be
found in my blog post
https://hackernoon.com/breaking-changes-26a2633f3415

10. Use serialisation formats designed for data
evolutions
1. Make everything optional
2. Properties are internally accessable by numeric id
3. You can deprecate properties
4. You can add properties with new id

11. Next up?

12. API
func createPerson(name: String, age: Int) -> Person

13. API additive non breaking change
func createPerson(name: String, age: Int, city: String? = nil) -> Person

14. Move the problem to data representation
func createPerson() -> Person
func send(person: Person)

15. How do we deal with breaking
changes in API?

16. Semantic versioning
X.Y.Z
~>

17. Semantic versioning
Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.

18. What about App versioning?

19. Who does REST?

20. Who knows
Richardson Maturity Model
???

21. https://de.wikipedia.org/wiki/RepresentationalStateTransfer

22. Who uses GraphQL?

23. Let's talk about architecture

24. https://de.wikipedia.org/wiki/Exzenterhaus

25. https://de.wikipedia.org/wiki/Universitätsklinikum_Aachen

26. Cooking & Gardening

27. Too many cooks spoil the broth

28. Ingredients and recipies

29. Gardening
Keeping your garden healthy

30. Last but not least, lets talk about
teams

33. The breaking change in a team is
about mental health
Not technical difficulties

34. The five keys to a successful Google team 1/2
1) Psychological safety: Can we take risks on this team without
feeling insecure or embarrassed?
2) Dependability: Can we count on each other to do high quality
work on time?
3) Structure & clarity: Are goals, roles, and execution plans on our
team clear?

35. The five keys to a successful Google team 2/2
4) Meaning of work: Are we working on something that is
personally important for each of us?
5) Impact of work: Do we fundamentally believe that the work
we’re doing matters?
https://rework.withgoogle.com/blog/five-keys-to-a-successful-
google-team/

36. However Fresh Blood in the Team is
also important

37. Recap
• Data representations
• API
• Versioning
• Apps
• Client server communication
• Architecture
• Team

38. Thank you!
@iceX33