Evolutionary Design Animated James Shore TWITTER: @jamesshore - - PowerPoint PPT Presentation

▶
evolutionary design animated
SMART_READER_LITE
LIVE PREVIEW

Evolutionary Design Animated James Shore TWITTER: @jamesshore - - PowerPoint PPT Presentation

May 12, 2023 132 likes •776 views

Evolutionary Design Animated James Shore TWITTER: @jamesshore jshore@jamesshore.com YOW! Conferences EMAIL: jamesshore.com December 2019 WEB: github.com/jamesshore Sydney/Brisbane/Melbourne, Australia GITHUB: jamesshore.com

slide-1
SLIDE 1

TWITTER: @jamesshore EMAIL: jshore@jamesshore.com WEB: jamesshore.com GITHUB: github.com/jamesshore YOW! Conferences December 2019 Sydney/Brisbane/Melbourne, Australia

Evolutionary Design Animated

James Shore

slide-2
SLIDE 2

jamesshore.com

slide-3
SLIDE 3

jamesshore.com

slide-4
SLIDE 4
slide-5
SLIDE 5
slide-6
SLIDE 6
slide-7
SLIDE 7
slide-8
SLIDE 8

jamesshore.com

Max Value

slide-9
SLIDE 9

jamesshore.com

Cost of each change → # of changes →

Traditional sofuware development XP’s assumption

“This is one of the premises of XP. It is the technical premise of XP… If a flattened change cost curve makes XP possible, a steep change cost curve makes XP impossible.”

—Kent Beck Extreme Programming Explained, 1st ed.

slide-10
SLIDE 10

jamesshore.com

slide-11
SLIDE 11

jamesshore.com

slide-12
SLIDE 12

jamesshore.com

Cost of each change (hrs) → # of changes →

Pointer (12 hrs) Lines (6.5 hrs) Clear button (2.75 hrs) Touch pointer (0.5 hr) Disappearing pointer (0.75 hr)

slide-13
SLIDE 13

jamesshore.com

Evolutionary Design

How to achieve the enabling technical premise of modern development.

slide-14
SLIDE 14
slide-15
SLIDE 15

jamesshore.com

Evolutionary Design

  • 1. Simple Design
  • 2. Continuous Design
  • 3. Reflective Design

all enabled by fast & reliable automated tests

}

How to achieve the enabling technical premise of modern development.

slide-16
SLIDE 16

jamesshore.com

When Not to Use Evolutionary Design

Avoid when refactoring is diffjcult or expensive

  • Not for interfaces exposed to other teams
  • unless you can directly change their code
  • implementation can use evolutionary design
  • For use within teams, not across teams
slide-17
SLIDE 17

jamesshore.com

slide-18
SLIDE 18

jamesshore.com

slide-19
SLIDE 19

jamesshore.com

slide-20
SLIDE 20

jamesshore.com

Simple Design

Design for exactly the features you have now

  • Start with a walking skeleton
  • Do The Simplest Thing That Could Possibly Work
  • You Aren't Gonna Need It
slide-21
SLIDE 21

jamesshore.com

slide-22
SLIDE 22

jamesshore.com

slide-23
SLIDE 23

jamesshore.com

slide-24
SLIDE 24

jamesshore.com

slide-25
SLIDE 25

jamesshore.com

Think Red Green Refactor

slide-26
SLIDE 26
slide-27
SLIDE 27

jamesshore.com

slide-28
SLIDE 28

jamesshore.com

Continuous Design

Constantly review and improve the design

  • Merciless Refactoring
  • Collective Ownership
  • Pairing and/or Mobbing
  • Continuous Integration
slide-29
SLIDE 29

jamesshore.com Adapted from Domain-Driven Design by Eric Evans

slide-30
SLIDE 30
slide-31
SLIDE 31

jamesshore.com

slide-32
SLIDE 32

jamesshore.com

slide-33
SLIDE 33

jamesshore.com

slide-34
SLIDE 34

jamesshore.com

slide-35
SLIDE 35

jamesshore.com

slide-36
SLIDE 36

jamesshore.com

Simple Design

Design for exactly the features you have now

  • Start with a walking skeleton
  • Do The Simplest Thing That Could Possibly Work
  • You Aren't Gonna Need It
  • Simple, not sloppy
slide-37
SLIDE 37

jamesshore.com

Rules for Simple Design

“When, not if, I need to change this decision in the future, how hard will it be?”

  • Every concept Once.
  • …And Only Once (Don’t Repeat Yourself)
  • Design intent clear and obvious
  • Concrete, not speculative
  • Cohesive: code that changes together, stays together
  • Decoupled: if it’s out of sight, it’s safely out of mind
  • Isolated: if it’s widely used, it’s abstracted by an interface
slide-38
SLIDE 38

jamesshore.com

slide-39
SLIDE 39

jamesshore.com

slide-40
SLIDE 40

jamesshore.com

slide-41
SLIDE 41

jamesshore.com

slide-42
SLIDE 42

jamesshore.com

Reflective Design

Focus your refactoring where it will do the most good.

slide-43
SLIDE 43

jamesshore.com

Traditional Design

  • 1. Imagine the features that the application will support.
  • 2. Imagine a design that can be cleanly extended to

support all possible features.

  • 3. Implement the design incrementally, leaving design

“hooks” for features you haven’t added.

slide-44
SLIDE 44

jamesshore.com

Reflective Design

Focus your refactoring where it will do the most good.

  • 1. Review the code you're about to work on.
  • 2. Identify flaws (“code smells,” diffjculty understanding).
  • 3. Reverse engineer design of code, if necessary.
  • 4. Imagine how to improve the design of the code.
  • 5. Incrementally refactor the code to reach desired design.
slide-45
SLIDE 45

jamesshore.com

slide-46
SLIDE 46

jamesshore.com

slide-47
SLIDE 47

jamesshore.com

slide-48
SLIDE 48

jamesshore.com

slide-49
SLIDE 49

jamesshore.com

slide-50
SLIDE 50

jamesshore.com

slide-51
SLIDE 51

jamesshore.com

slide-52
SLIDE 52

jamesshore.com

slide-53
SLIDE 53

jamesshore.com

slide-54
SLIDE 54

jamesshore.com

Continuous Design

Constantly review and improve the design

  • Merciless Refactoring
  • Collective Ownership
  • Pairing and/or Mobbing
  • Continuous Integration
  • Camp Site Rule: Don’t make it perfect; just make it

better.

slide-55
SLIDE 55

jamesshore.com

Continuous Design

Constantly review and improve the design

  • Merciless Refactoring
  • Collective Ownership
  • Pairing and/or Mobbing
  • Continuous Integration
  • Camp Site Rule: Don’t make it perfect; just make it

better.

  • Be prepared to be surprised!
slide-56
SLIDE 56

jamesshore.com

slide-57
SLIDE 57

jamesshore.com

slide-58
SLIDE 58

jamesshore.com

Evolutionary Design

  • 1. Simple Design
  • 2. Continuous Design
  • 3. Reflective Design

all enabled by fast & reliable automated tests

}

How to achieve the enabling technical premise of modern development.

slide-59
SLIDE 59

jamesshore.com

Simple Design

Design for exactly the features you have now

  • Start with a walking skeleton
  • Do The Simplest Thing That Could Possibly Work
  • You Aren't Gonna Need It
  • Simple, not sloppy
slide-60
SLIDE 60

jamesshore.com

Continuous Design

Constantly review and improve the design

  • Merciless Refactoring
  • Collective Ownership
  • Pairing and/or Mobbing
  • Continuous Integration
  • Camp Site Rule: Don’t make it perfect; just make it

better.

  • Be prepared to be surprised!
slide-61
SLIDE 61

jamesshore.com

Reflective Design

Focus your refactoring where it will do the most good.

  • 1. Review the code you're about to work on.
  • 2. Identify flaws (“code smells,” diffjculty understanding).
  • 3. Reverse engineer design of code, if necessary.
  • 4. Imagine how to improve the design of the code.
  • 5. Incrementally refactor the code to reach desired design.
slide-62
SLIDE 62

jamesshore.com

Cost of each change (hrs) → # of changes →

Pointer (12 hrs) Lines (6.5 hrs) Clear button (2.75 hrs) Touch pointer (0.5 hr) Disappearing pointer (0.75 hr)

slide-63
SLIDE 63

jamesshore.com

slide-64
SLIDE 64

TWITTER: @jamesshore EMAIL: jshore@jamesshore.com WEB: jamesshore.com GITHUB: github.com/jamesshore YOW! Conferences December 2019 Sydney/Brisbane/Melbourne, Australia

Evolutionary Design Animated

James Shore

“Flight of the Bumblebee” by Nikolai Rimsky-Korsakov

Royalty-free recording courtesy of videvo.net