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

Experience Report: Feature Parity in 25% of the Dev Hours

Experience Report: Feature Parity in 25% of the Dev Hours

Quinn

May 24, 2019
Tweet

More Decks by Quinn

Other Decks in Programming

Transcript

  1. Feature
    Parity in
    25% Dev
    Hours

    View full-size slide

  2. Quinn Gil
    (last talk, last day)
    @TheQuinnGil
    QuinnGil.com

    View full-size slide

  3. The Story ● Rewrite of mobile apps (iOS, Android, Windows)
    ● Started iOS & Android
    ● 9m into dev (only 2/3 complete) started Windows
    ● Given ½ the team.
    ● Given only 7 months to develop the same features
    ● Asking the impossible - But OK - With Conditions
    ○ BENEVOLENT DICTATOR
    ○ Strict XP
    ○ Strict set of Technical Practices
    ● I’ll learn, even if I don’t succeed
    ○ Heard XP is great, never saw strict application
    ○ Heard the code practices are great, never saw in action
    ● Everyone agreed, and I started my dictatorship
    ● Result - 7m version is available in the store.
    ● XP & Technical Practices WORK!
    ● 25% of Dev hours for Feature Parity.

    View full-size slide

  4. Why did it work? ● PO / Customer in arms length
    ● Pair+ Programming
    ○ Hours of discussion to remove a single line
    ○ Which enabled refactoring 30% of the code
    ○ Included PO/Customer
    ○ Included Design
    ● Sustainable Pace / NO Crunch Time
    ● #NoEstimates
    ● Refactoring
    ● Emergent Architecture / Simple Design
    ● Testing
    ● Continuous Delivery
    ● Coding Standards
    ● Collective Ownership
    ○ Devs challenge design
    ○ Design challenge devs
    eXtreme Programming

    View full-size slide

  5. Why did it work? Good code invariably has small
    methods and small objects. Only by
    factoring the system into many small
    pieces of state and function can you
    hope to satisfy the “once and only
    once” rule. ... [N]o one thing I do to
    systems provides as much help as
    breaking it into more pieces.
    Kent Beck - Smalltalk Best
    Practice Patterns `97
    The Technical Practices

    View full-size slide

  6. Technical Practices
    ● No Getters / No Setters
    ● `if` Only As Guard Clause
    ● Isolate Their Code
    ● Never `null`
    ● No `new` inline
    ● Composition, Not Inheritance

    ● Be Immutable
    ● No Primitives
    ● Extract Cohesion
    ● No Public Statics
    ● Never Reflection
    @TheQuinnGil QuinnGil.com

    View full-size slide

  7. Why did it work? Good code invariably has small
    methods and small objects. Only by
    factoring the system into many small
    pieces of state and function can you
    hope to satisfy the “once and only
    once” rule. ... [N]o one thing I do to
    systems provides as much help as
    breaking it into more pieces.
    Kent Beck - Smalltalk Best
    Practice Patterns `97
    The Technical Practices result in
    SmallTalk style in C#

    View full-size slide

  8. Why isn’t this
    common?

    View full-size slide

  9. Is Hard
    Change

    View full-size slide

  10. Change Is Hard
    Even when it’s better.

    View full-size slide

  11. Change Is Hard
    Even when it’s better.
    Demonstrably better.

    View full-size slide

  12. Change Is Hard Good code invariably has small
    methods and small objects. Only by
    factoring the system into many small
    pieces of state and function can you
    hope to satisfy the “once and only
    once” rule. ... [N]o one thing I do to
    systems provides as much help as
    breaking it into more pieces.
    Kent Beck - Smalltalk Best
    Practice Patterns `97

    View full-size slide

  13. Change Is Hard Good code invariably has small methods and small
    objects. Only by factoring the system into many small
    pieces of state and function can you hope to satisfy the
    “once and only once” rule.
    I get lots of resistance
    to this idea, especially
    from experienced
    developers,
    but no one thing I do to systems provides as much help as
    breaking it into more pieces.

    View full-size slide

  14. Change Is Hard
    Biggest Lesson For Me

    View full-size slide

  15. Is Different
    XP

    View full-size slide

  16. XP Is Hard
    XP requires strong
    technical practices

    View full-size slide

  17. XP Is Hard ● Typical coding is imperative
    XP requires strong
    technical practices

    View full-size slide

  18. XP Is Hard ● Typical coding is imperative
    ● Good object oriented code interacts
    differently
    XP requires strong
    technical practices

    View full-size slide

  19. XP Is Hard ● Typical coding is imperative
    ● Good object oriented code interacts
    differently
    ● We think differently
    XP requires strong
    technical practices

    View full-size slide

  20. XP Is Hard ● Typical coding is imperative
    ● Good object oriented code interacts
    differently
    ● We think differently
    Good object oriented code requires a
    mindset change
    XP requires strong
    technical practices

    View full-size slide

  21. XP Is Hard ● Typical coding is imperative
    ● Good object oriented code interacts
    differently
    ● We think differently
    Good object oriented code requires a
    mindset change
    ● Good practices are change/hard
    XP requires strong
    technical practices

    View full-size slide

  22. XP Is Hard ● Typical coding is imperative
    ● Good object oriented code interacts
    differently
    ● We think differently
    Good object oriented code requires a
    mindset change
    ● Good practices are change/hard
    ● Easy to be discouraged
    XP requires strong
    technical practices

    View full-size slide

  23. XP Is Hard ● Typical coding is imperative
    ● Good object oriented code interacts
    differently
    ● We think differently
    Good object oriented code requires a
    mindset change
    ● Good practices are change/hard
    ● Easy to be discouraged
    ● Hard to learn alone
    XP requires strong
    technical practices

    View full-size slide

  24. XP Works,
    We Know.
    It’s why we’re here.

    View full-size slide

  25. XP Works,
    We Know.
    ● Long time w/o substantial adoption
    It’s why we’re here.

    View full-size slide

  26. XP Works,
    We Know.
    ● Long time w/o substantial adoption
    “I get lots of resistance to this idea,
    especially from experienced
    developers”
    It’s why we’re here.

    View full-size slide

  27. XP Works,
    We Know.
    ● Long time w/o substantial adoption
    “I get lots of resistance to this idea,
    especially from experienced
    developers”
    ● Why?
    It’s why we’re here.

    View full-size slide

  28. XP Works,
    We Know.
    ● Long time w/o substantial adoption
    “I get lots of resistance to this idea,
    especially from experienced
    developers”
    ● Why? - Experience not doing it
    It’s why we’re here.

    View full-size slide

  29. XP Works,
    We Know.
    ● Long time w/o substantial adoption
    “I get lots of resistance to this idea,
    especially from experienced
    developers”
    ● Why? - Experience not doing it
    ● Some practices showing up
    ○ (Sec)DevOps
    ○ Pair+ Programming
    ○ Collective Code Ownership
    It’s why we’re here.

    View full-size slide

  30. Make Change
    Happen?

    View full-size slide

  31. Make Change
    Happen?
    ● This

    View full-size slide

  32. Make Change
    Happen?
    ● This
    ● Show the results

    View full-size slide

  33. Make Change
    Happen?
    ● This
    ● Show the results
    ● Iron Fist

    View full-size slide

  34. What Changes? ● How we write the code

    View full-size slide

  35. What Changes? ● How we write the code
    ● How we build the code

    View full-size slide

  36. What Changes? ● How we write the code
    ● How we build the code
    ● How we think about code

    View full-size slide

  37. Absent
    Technical
    Practices
    ● Can’t go faster
    ● Can’t get ~zero defects
    ● Can’t test quickly
    ● Can’t share workload
    ● Can’t change code easily

    View full-size slide

  38. With
    Technical
    Practices
    ● 25% the Developer Hours
    ● Zero Code Defects

    View full-size slide

  39. Feature
    Parity in
    25% Dev
    Hours

    View full-size slide

  40. Technical Practices
    ● No Getters / No Setters
    ● `if` Only As Guard Clause
    ● Isolate Their Code
    ● Never `null`
    ● No `new` inline
    ● Composition, Not Inheritance

    ● Be Immutable
    ● No Primitives
    ● Extract Cohesion
    ● No Public Statics
    ● Never Reflection
    @TheQuinnGil QuinnGil.com

    View full-size slide