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

Slide 1

Slide 1 text

Feature Parity in 25% Dev Hours

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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.

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Why isn’t this common?

Slide 9

Slide 9 text

Change

Slide 10

Slide 10 text

Is Hard Change

Slide 11

Slide 11 text

Change Is Hard Even when it’s better.

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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.

Slide 15

Slide 15 text

Change Is Hard Biggest Lesson For Me

Slide 16

Slide 16 text

Is Different XP

Slide 17

Slide 17 text

Is Change XP

Slide 18

Slide 18 text

XP Is Hard XP requires strong technical practices

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Works XP

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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.

Slide 30

Slide 30 text

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.

Slide 31

Slide 31 text

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.

Slide 32

Slide 32 text

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.

Slide 33

Slide 33 text

Make Change Happen?

Slide 34

Slide 34 text

Make Change Happen? ● This

Slide 35

Slide 35 text

Make Change Happen? ● This ● Show the results

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

What Changes? ● How we write the code

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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