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

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

5b92c5ea42bc2c2ab28d973d5da63cd6?s=128

Quinn

May 24, 2019
Tweet

Transcript

  1. Feature Parity in 25% Dev Hours

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

  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.
  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
  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
  6. Technical Practices • No Getters / No Setters • `if`

    Only As Guard Clause • Isolate Their Code • Never `null` • No `new` inline • Composition, Not Inheritance • <Strong opinions, loosely held> • Be Immutable • No Primitives • Extract Cohesion • No Public Statics • Never Reflection @TheQuinnGil QuinnGil.com
  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#
  8. Why isn’t this common?

  9. Change

  10. Is Hard Change

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

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

  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. ... [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
  14. 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.
  15. Change Is Hard Biggest Lesson For Me

  16. Is Different XP

  17. Is Change XP

  18. XP Is Hard XP requires strong technical practices

  19. XP Is Hard • Typical coding is imperative XP requires

    strong technical practices
  20. XP Is Hard • Typical coding is imperative • Good

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

    object oriented code interacts differently • We think differently XP requires strong technical practices
  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 XP requires strong technical practices
  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 XP requires strong technical practices
  24. 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
  25. 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
  26. Works XP

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

  28. XP Works, We Know. • Long time w/o substantial adoption

    It’s why we’re here.
  29. 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.
  30. 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.
  31. 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.
  32. 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.
  33. Make Change Happen?

  34. Make Change Happen? • This

  35. Make Change Happen? • This • Show the results

  36. Make Change Happen? • This • Show the results •

    Iron Fist
  37. What Changes? • How we write the code

  38. What Changes? • How we write the code • How

    we build the code
  39. What Changes? • How we write the code • How

    we build the code • How we think about code
  40. 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
  41. With Technical Practices • 25% the Developer Hours • Zero

    Code Defects
  42. Feature Parity in 25% Dev Hours

  43. Technical Practices • No Getters / No Setters • `if`

    Only As Guard Clause • Isolate Their Code • Never `null` • No `new` inline • Composition, Not Inheritance • <Strong opinions, loosely held> • Be Immutable • No Primitives • Extract Cohesion • No Public Statics • Never Reflection @TheQuinnGil QuinnGil.com