16 June 2015 © Agile Institute 2008-2014 1
16 June 2015 © Agile Institute 2008-2014 2
Emergent
Design
History, Concepts, &
Principles
Rob Myers
Agile Development Practices
East
13 November 2014
a definition of emergence
16 June 2015 © Agile Institute 2008-2014 3
…a process whereby larger entities, patterns, and
regularities arise through interactions among
smaller or simpler entities that themselves do not
exhibit such properties.
-- http://en.wikipedia.org/wiki/Emergence
16 June 2015 © Agile Institute 2008-2014 4
16 June 2015 © Agile Institute 2008-2014 5
16 June 2015 © Agile Institute 2008-2014 6
16 June 2015 © Agile Institute 2008-2014 7
16 June 2015 © Agile Institute 2008-2014 8
16 June 2015 © Agile Institute 2008-2014 9
"Termite Cathedral DSC03570”
taken by w:User:Yewenyi - [1].
Licensed under
Creative Commons Attribution-Share Alike 3.0
via Wikimedia Commons
http://commons.wikimedia.org/wiki/
16 June 2015 © Agile Institute 2008-2014 10
16 June 2015 © Agile Institute 2008-2014 11
emergent properties
• Spontaneous order arises from chaos.
• From simple rules, complex behaviors manifest.
• Tiny steps, repeated many times, perhaps recursively.
• Same “rules” apply at macro/micro levels; same “paths”
exist to/from another level.
• Require a rich supply of “food”: time, energy, RAM…
16 June 2015 © Agile Institute 2008-2014 12
What would “Emergent Design” mean?
A software design which
• solves the problems or implements the business
behaviors requested,
• emerged over time,
• emerged from simple rules and trusted practices,
• is elegant and easy to maintain,
• was not considered beforehand,
• was discovered along the way!
16 June 2015 © Agile Institute 2008-2014 13
16 June 2015 © Agile Institute 2008-2014 14
A Brief History of
Object Oriented Design
object oriented programming
• Modular programming taken further: Keep data together
with operations that commonly apply to that data.
• Allows us to create types & abstractions useful in our
domain.
• Replaces structure, e.g.
if (lastLocationKnown) {
doSomethingClever();
} else {
doSomethingQuick();
}
with state
nextMove = whatToDoNext(lastLocationKnown);
nextMove.doIt();
16 June 2015 © Agile Institute 2008-2014 15
encapsulation
• Hiding data & implementation, and also design, type,
cardinality, construction...
• Hidden from whom or what?
• Why?
• Favor strong encapsulation, but reveal what’s needed.
16 June 2015 © Agile Institute 2008-2014 16
cohesion
• How closely the methods in a class are related.
• A class or method is about one thing.
• Business logic and database access are, by the way, two
things!
• Is more cohesion good or bad?
• Why?
16 June 2015 © Agile Institute 2008-2014 17
coupling
• A class or method’s knowledge about another class.
• Good encapsulation reduces coupling.
• Intentional (“good”), and accidental (“bad”).
16 June 2015 © Agile Institute 2008-2014 18
spot the accidental coupling
16 June 2015 © Agile Institute 2008-2014 19
// my first PseudoJava#.Net++Script program…
public Collection<User> findGroup(Group whichGroup) {…}
…
{
…
OrderedList<User> friends =
(OrderedList<User>) findGroup(FRIENDS);
friends.first().message(“Have you tried Cow Clicker?”);
}
16 June 2015 © Agile institute 2008-2014 20
Move
+ void doIt(Board board)
Quick
+ void doIt()
Player
+ takeTurn()
Types of Coupling
DeepThought
+ Move nextMove() Clever
+ void doIt()
Identity
Representational
Inheritance
Subclass
Player
+ void takeTurn()
16 June 2015 © Agile institute 2008-2014 21
Player
+ void takeTurn()
Types of Coupling
DeepThought
+ Move nextMove()
public void takeTurn() {
Move myMove = deepThought.nextMove();
myMove.doIt();
}
Identity
Representational
public Move nextMove() {
if (otherPlayer.lastLocationKnown()) {
return new Clever();
else {
return new Quick();
}
}
Subclass
Polymorphism
• Abstraction & substitutability: A powerful design feature.
• Inheritance.
• Is there a down-side to inheritance?
16 June 2015 © Agile Institute 2008-2014 22
16 June 2015 © Agile Institute 2008-2014 23
(Duplication)
• A negative attribute: We want less of it.
• There are many forms of duplication besides the results of
simple copy/paste/modify.
• Modularity, objects, polymorphism are all used to reduce
this.
• Why is duplication to be avoided?
16 June 2015 © Agile Institute 2008-2014 24
Testability
• The ability to verify the behaviors of an object.
• How would the following support this?
• Good cohesion.
• Only necessary coupling.
• Less duplication.
16 June 2015 © Agile Institute 2008-2014 25
16 June 2015 © Agile Institute 2008-2014 26
Wisdom of
Design Patterns
16 June 2015 © Agile institute 2008-2014 27
Stream
BinaryStream
(Subclassing for Specialization)
CharacterStream
EncryptedCharacterStream CompressedCharacterStream
EncryptedBinaryStreamStream
EncryptedNetworkCharacterStrea
m
EncryptedFilesystemCharacterStream
16 June 2015 © Agile institute 2008-2014 28
Stream
1. Favor object (instance) delegation over class inheritance
Mode
Binary Character
Device
Network Filesystem
Stream
StreamDecorator
EncryptedStream CompressedStrea
m
Psychi
16 June 2015 © Agile institute 2008-2014 29
Stream
2. Design to types, not implementations.
Mode
Binary Character
Device
Network Filesystem Psychi
16 June 2015 © Agile institute 2008-2014 30
Stream
3. Encapsulate any variation.
Mode
Binary Character
Device
Network Filesystem Psychi
16 June 2015 © Agile institute 2008-2014 31
4. Design objects for their primary use,
then design how to build the object graph.
Move
+ void doIt(Board board)
Quick
+ void doIt()
Player
+ takeTurn()
DeepThought
+ Move nextMove() Clever
+ void doIt()
Player
+ void takeTurn()
Use
Construction
16 June 2015 © Agile Institute 2008-2014 32
16 June 2015 © Agile Institute 2008-2014 33
Single Responsibility Principle.
Open-Closed Principle.
Liskov Substitution Principle.
Interface Segregation Principle.
Dependency Inversion Principle.
16 June 2015 © Agile Institute 2008-2014 34
emergence
16 June 2015 © Agile Institute 2008-2014 35
Developer’s “Oath of Athens”
I vow to
leave the
code as
good as I
found it,
or better!
16 June 2015 © Agile Institute 2008-2014 36
Runs all the tests.
Expresses every idea required.
Says everything once and only once.
Has no superfluous parts.
Kent Beck’s Four Rules of Simple Design
16 June 2015 © Agile Institute 2008-2014 37
Relentless Refactoring
16 June 2015 © Agile Institute 2008-2014 38
allowing emergence to occur
• We follow simple rules and practices with dedication and
effort.
• We keep pragmatic knowledge fresh and let go of any
obsolete opinions.
• We pay attention to quality craftsmanship whether building
the “big picture” or the fine details.
16 June 2015 © Agile Institute 2008-2014 39
16 June 2015 © Agile Institute 2008-2014 40
16 June 2015 © Agile Institute 2008-2014 41
16 June 2015 © Agile Institute 2008-2014 42
Rob.Myers@agileInstitute.com
http://PowersOfTwo.agileInstitute.com/
@agilecoach
summary of practices that enable
emergent design
• Relentless Refactoring: We design incrementally, so the design is always very
good given the current known functionality and the amount of effort expended. We
take very rapid, but careful, baby-steps. We don’t overdesign for the far-flung future.
This leaves us always with an adaptable (soft!) software system.
• Simple Design: We acknowledge that clarity and malleability are at the heart of all
good software design strategies.
• TDD/BDD: We write new functionality by considering, and writing, a simple script of
conditions & expectations (inputs & outputs) before implementing the solution to that
specification. This greatly reduces defects, and provides a fast-acting safety-net,
allowing us to refactor with confidence.
• Collaborative Accountability: We allow knowledge, architectural & design skills,
and responsibilities to propagate and improve. Any code can be altered by any
teammate. This is implemented using other essential Agile engineering practices such
as Collective Code Ownership, Continuous Integration, Pair Programming, Sitting
Together, Continuous Learning, and Sustainable Pace.
16 June 2015 © Agile Institute 2008-2014 43
summary of
emergent design properties
• By testing behaviors and interactions in isolation, we test all complex
behaviors without creating a slow, unmaintainable suite of tests.
• Small objects that handle what they know, and delegate when
necessary, allow us to create very flexible and valuable functionality.
• The safety-net of fast regression tests allows us to continuously
improve design (refactor) in tiny steps, and reshape it to introduce
new behavioral variations without disruption.
• There is no hierarchy of important/unimportant code. The behavior
and design we are currently adding or changing is where we apply our
energy and attention.
• Our teams thrive on collaboration, continuous learning, disciplined
effort, dedication to quality, mutual trust, and tasty snacks.
16 June 2015 © Agile Institute 2008-2014 44

Emergent Design: History, Concepts, and Principles

  • 1.
    16 June 2015© Agile Institute 2008-2014 1
  • 2.
    16 June 2015© Agile Institute 2008-2014 2 Emergent Design History, Concepts, & Principles Rob Myers Agile Development Practices East 13 November 2014
  • 3.
    a definition ofemergence 16 June 2015 © Agile Institute 2008-2014 3 …a process whereby larger entities, patterns, and regularities arise through interactions among smaller or simpler entities that themselves do not exhibit such properties. -- http://en.wikipedia.org/wiki/Emergence
  • 4.
    16 June 2015© Agile Institute 2008-2014 4
  • 5.
    16 June 2015© Agile Institute 2008-2014 5
  • 6.
    16 June 2015© Agile Institute 2008-2014 6
  • 7.
    16 June 2015© Agile Institute 2008-2014 7
  • 8.
    16 June 2015© Agile Institute 2008-2014 8
  • 9.
    16 June 2015© Agile Institute 2008-2014 9 "Termite Cathedral DSC03570” taken by w:User:Yewenyi - [1]. Licensed under Creative Commons Attribution-Share Alike 3.0 via Wikimedia Commons http://commons.wikimedia.org/wiki/
  • 10.
    16 June 2015© Agile Institute 2008-2014 10
  • 11.
    16 June 2015© Agile Institute 2008-2014 11
  • 12.
    emergent properties • Spontaneousorder arises from chaos. • From simple rules, complex behaviors manifest. • Tiny steps, repeated many times, perhaps recursively. • Same “rules” apply at macro/micro levels; same “paths” exist to/from another level. • Require a rich supply of “food”: time, energy, RAM… 16 June 2015 © Agile Institute 2008-2014 12
  • 13.
    What would “EmergentDesign” mean? A software design which • solves the problems or implements the business behaviors requested, • emerged over time, • emerged from simple rules and trusted practices, • is elegant and easy to maintain, • was not considered beforehand, • was discovered along the way! 16 June 2015 © Agile Institute 2008-2014 13
  • 14.
    16 June 2015© Agile Institute 2008-2014 14 A Brief History of Object Oriented Design
  • 15.
    object oriented programming •Modular programming taken further: Keep data together with operations that commonly apply to that data. • Allows us to create types & abstractions useful in our domain. • Replaces structure, e.g. if (lastLocationKnown) { doSomethingClever(); } else { doSomethingQuick(); } with state nextMove = whatToDoNext(lastLocationKnown); nextMove.doIt(); 16 June 2015 © Agile Institute 2008-2014 15
  • 16.
    encapsulation • Hiding data& implementation, and also design, type, cardinality, construction... • Hidden from whom or what? • Why? • Favor strong encapsulation, but reveal what’s needed. 16 June 2015 © Agile Institute 2008-2014 16
  • 17.
    cohesion • How closelythe methods in a class are related. • A class or method is about one thing. • Business logic and database access are, by the way, two things! • Is more cohesion good or bad? • Why? 16 June 2015 © Agile Institute 2008-2014 17
  • 18.
    coupling • A classor method’s knowledge about another class. • Good encapsulation reduces coupling. • Intentional (“good”), and accidental (“bad”). 16 June 2015 © Agile Institute 2008-2014 18
  • 19.
    spot the accidentalcoupling 16 June 2015 © Agile Institute 2008-2014 19 // my first PseudoJava#.Net++Script program… public Collection<User> findGroup(Group whichGroup) {…} … { … OrderedList<User> friends = (OrderedList<User>) findGroup(FRIENDS); friends.first().message(“Have you tried Cow Clicker?”); }
  • 20.
    16 June 2015© Agile institute 2008-2014 20 Move + void doIt(Board board) Quick + void doIt() Player + takeTurn() Types of Coupling DeepThought + Move nextMove() Clever + void doIt() Identity Representational Inheritance Subclass Player + void takeTurn()
  • 21.
    16 June 2015© Agile institute 2008-2014 21 Player + void takeTurn() Types of Coupling DeepThought + Move nextMove() public void takeTurn() { Move myMove = deepThought.nextMove(); myMove.doIt(); } Identity Representational public Move nextMove() { if (otherPlayer.lastLocationKnown()) { return new Clever(); else { return new Quick(); } } Subclass
  • 22.
    Polymorphism • Abstraction &substitutability: A powerful design feature. • Inheritance. • Is there a down-side to inheritance? 16 June 2015 © Agile Institute 2008-2014 22
  • 23.
    16 June 2015© Agile Institute 2008-2014 23
  • 24.
    (Duplication) • A negativeattribute: We want less of it. • There are many forms of duplication besides the results of simple copy/paste/modify. • Modularity, objects, polymorphism are all used to reduce this. • Why is duplication to be avoided? 16 June 2015 © Agile Institute 2008-2014 24
  • 25.
    Testability • The abilityto verify the behaviors of an object. • How would the following support this? • Good cohesion. • Only necessary coupling. • Less duplication. 16 June 2015 © Agile Institute 2008-2014 25
  • 26.
    16 June 2015© Agile Institute 2008-2014 26 Wisdom of Design Patterns
  • 27.
    16 June 2015© Agile institute 2008-2014 27 Stream BinaryStream (Subclassing for Specialization) CharacterStream EncryptedCharacterStream CompressedCharacterStream EncryptedBinaryStreamStream EncryptedNetworkCharacterStrea m EncryptedFilesystemCharacterStream
  • 28.
    16 June 2015© Agile institute 2008-2014 28 Stream 1. Favor object (instance) delegation over class inheritance Mode Binary Character Device Network Filesystem Stream StreamDecorator EncryptedStream CompressedStrea m Psychi
  • 29.
    16 June 2015© Agile institute 2008-2014 29 Stream 2. Design to types, not implementations. Mode Binary Character Device Network Filesystem Psychi
  • 30.
    16 June 2015© Agile institute 2008-2014 30 Stream 3. Encapsulate any variation. Mode Binary Character Device Network Filesystem Psychi
  • 31.
    16 June 2015© Agile institute 2008-2014 31 4. Design objects for their primary use, then design how to build the object graph. Move + void doIt(Board board) Quick + void doIt() Player + takeTurn() DeepThought + Move nextMove() Clever + void doIt() Player + void takeTurn() Use Construction
  • 32.
    16 June 2015© Agile Institute 2008-2014 32
  • 33.
    16 June 2015© Agile Institute 2008-2014 33 Single Responsibility Principle. Open-Closed Principle. Liskov Substitution Principle. Interface Segregation Principle. Dependency Inversion Principle.
  • 34.
    16 June 2015© Agile Institute 2008-2014 34 emergence
  • 35.
    16 June 2015© Agile Institute 2008-2014 35 Developer’s “Oath of Athens” I vow to leave the code as good as I found it, or better!
  • 36.
    16 June 2015© Agile Institute 2008-2014 36 Runs all the tests. Expresses every idea required. Says everything once and only once. Has no superfluous parts. Kent Beck’s Four Rules of Simple Design
  • 37.
    16 June 2015© Agile Institute 2008-2014 37 Relentless Refactoring
  • 38.
    16 June 2015© Agile Institute 2008-2014 38
  • 39.
    allowing emergence tooccur • We follow simple rules and practices with dedication and effort. • We keep pragmatic knowledge fresh and let go of any obsolete opinions. • We pay attention to quality craftsmanship whether building the “big picture” or the fine details. 16 June 2015 © Agile Institute 2008-2014 39
  • 40.
    16 June 2015© Agile Institute 2008-2014 40
  • 41.
    16 June 2015© Agile Institute 2008-2014 41
  • 42.
    16 June 2015© Agile Institute 2008-2014 42 Rob.Myers@agileInstitute.com http://PowersOfTwo.agileInstitute.com/ @agilecoach
  • 43.
    summary of practicesthat enable emergent design • Relentless Refactoring: We design incrementally, so the design is always very good given the current known functionality and the amount of effort expended. We take very rapid, but careful, baby-steps. We don’t overdesign for the far-flung future. This leaves us always with an adaptable (soft!) software system. • Simple Design: We acknowledge that clarity and malleability are at the heart of all good software design strategies. • TDD/BDD: We write new functionality by considering, and writing, a simple script of conditions & expectations (inputs & outputs) before implementing the solution to that specification. This greatly reduces defects, and provides a fast-acting safety-net, allowing us to refactor with confidence. • Collaborative Accountability: We allow knowledge, architectural & design skills, and responsibilities to propagate and improve. Any code can be altered by any teammate. This is implemented using other essential Agile engineering practices such as Collective Code Ownership, Continuous Integration, Pair Programming, Sitting Together, Continuous Learning, and Sustainable Pace. 16 June 2015 © Agile Institute 2008-2014 43
  • 44.
    summary of emergent designproperties • By testing behaviors and interactions in isolation, we test all complex behaviors without creating a slow, unmaintainable suite of tests. • Small objects that handle what they know, and delegate when necessary, allow us to create very flexible and valuable functionality. • The safety-net of fast regression tests allows us to continuously improve design (refactor) in tiny steps, and reshape it to introduce new behavioral variations without disruption. • There is no hierarchy of important/unimportant code. The behavior and design we are currently adding or changing is where we apply our energy and attention. • Our teams thrive on collaboration, continuous learning, disciplined effort, dedication to quality, mutual trust, and tasty snacks. 16 June 2015 © Agile Institute 2008-2014 44

Editor's Notes

  • #3 Be sure to pass out files or have someone establish a read-only share. 25 yrs in the industry Using TDD and coaching XP/Scrum since 1998 Teaching TDD courses since 2001
  • #5 Fractals of course
  • #6 Mountains and rivers We tend to find these in nature. We tend to think of them as elegantly beautiful, and either relaxing or fearsome.
  • #7 snowflakes
  • #8 Romanesco broccoli
  • #9 A selfie of the early universe.
  • #11 Requires energy. Same rules apply at macro/micro level, as well as creating path from micro to macro and back again. From simple rules, complex behaviors arise. Ant hills, termite mounds, wasp nests, fractals, weather patterns, tree growth, rivers, galaxies, and quite possibly the multiverse.
  • #14 To succeed at this game, you have to trust the practices and the rules. In order to trust, you have to see where they’ve been.
  • #17 Maintainability, not secrecy. <click>
  • #18 Maintainability
  • #19 Maintainable systems should be as decoupled as possible. That does not mean we can have no coupling. Coupling is what makes a system work - object must be able to work together to create the architecture of the application in the first place. We want to understand, control, and simplify the coupling in the system.
  • #21 Four kinds: Identity Coupling – is when one type is coupled to the fact that another type exists. class WidgetContainer { Widget myWidget; // WidgetContainer is Identity coupled to Widget } Representational Coupling – is when you call a method on a class myWidget.doWidgetStuff(); // This is representational coupling Inheritance Coupling – when have a derivation, what is the coupling of different subclasses to its inheritance hierarchy Subclass Coupling – if the client only knows about Widget (doesn’t know about sub-classes) then there is no subclass coupling, otherwise there is. Not having subclass coupling allows me to change subclasses without affecting the client object using them. WOULD BE GOOD TO INCLUDE PRINCIPLES THAT ALLOWS THIS TO HAPPEN. Maintainable systems should be as decoupled as possible. That does not mean we can have no coupling. Coupling is what makes a system work - object must be able to work together to create the architecture of the application in the first place. We want to understand, control, and simplify the coupling in the system. Here are the four types of coupling we have to deal with (explain them).
  • #23 The strongest form of coupling.
  • #24 A Perfectly Good Editing Technique…Not a good DESIGN technique. YOU must clean it up! Two classes have similar interfaces or encapsulate similar concepts.
  • #29 Use class hierarchy to categorize, not specialize. One level is usually enough. Abstraction, and concrete implementation.
  • #30 Originally “Design to interfaces” Concrete code delegates to abstractions. Favor Representational coupling over subclass coupling. Increases flexibility! Replacing structural code with runtime state, then behaviors can change at runtime!
  • #31 Objects encapsulate data and related behavior. Hierarchy encapsulates variation of implementation. Many other things can be encapsulated.
  • #32 Originally “Design to interfaces” Concrete code delegates to abstractions. Favor Representational coupling over subclass coupling. Increases flexibility! Replacing structural code with runtime state, then behaviors can change at runtime!
  • #33 SRP: Cohesion OCP: Points to an advanced use of encapsulation and polymorphism. Liskov: Semantic not syntactic. Behavioral inheritance, not literal. CatTigerBengal TigerWhite Bengal Tiger & the Mantecore Confusion Interface Segregation: Relates to cohesion. Using narrow interfaces. Since we’re not really talking about a particular language, essentially narrow type interfaces: few public methods, small objects. DIP: Inversion compared to traditional old structured analysis and decomposition. Top-down doesn’t work, bottom-up creates similar couplings. Decoupling via abstractions where necessary. Layers of abstraction. Design to types, + Encapsulates Variation “up” or “down”. The types you communicate with should make sense for what you are trying to accomplish. And so it goes at every level, and in every direction. This is also the primary legitimate use of Java interfaces, as contracts to be established between client and service.
  • #34 SRP: Cohesion OCP: Points to an advanced use of encapsulation and polymorphism. Liskov: Semantic not syntactic. Behavioral inheritance, not literal. CatTigerBengal TigerWhite Bengal Tiger & the Mantecore Confusion Interface Segregation: Relates to cohesion. Using narrow interfaces. Since we’re not really talking about a particular language, essentially narrow type interfaces: few public methods, small objects. DIP: Inversion compared to traditional old structured analysis and decomposition. Top-down doesn’t work, bottom-up creates similar couplings. Decoupling via abstractions where necessary. Layers of abstraction. Design to types, + Encapsulates Variation “up” or “down”. The types you communicate with should make sense for what you are trying to accomplish. And so it goes at every level, and in every direction. This is also the primary legitimate use of Java interfaces, as contracts to be established between client and service.
  • #35 That’s a lot to learn! Learn them at your own pace. In the mean time, we need to keep designs fluid, so they can change. In fact, one very good definition of a good design is a design that can adapt to change: Maintainability and extensibility. So, beyond keeping every possible variation open-closed and decoupled, and yet still readable and maintainable by humans, what can we do? Order arising from chaos in a series of tiny steps, resulting in “emergent properties.” Requires energy. Same rules apply at macro/micro level, as well as creating path from micro to macro and back again. From simple rules, complex behaviors arise. Ant hills, termite mounds, wasp nests, fractals, weather patterns, tree growth, rivers, galaxies, and quite possibly the multiverse.
  • #37 Note what Kent isn’t talking about here: OO! Why? He’s either forgotten, or is assuming, all the prior OO/DP knowledge. In an emergent context, as you work with an OO language with these rules, you will eventually “re-learn” all prior wisdom. It’s easier if you know it, but not impossible if you don’t.
  • #38 Refactoring IS design!
  • #39 TDD (pairing doesn’t hurt either)
  • #40 YOU are the engine of emergence!
  • #43 Thank you!
  • #45 Spontaneous order arises from chaos. From simple rules, complex behaviors manifest. Tiny steps, repeated many times, perhaps recursively. Same “rules” apply at macro/micro levels; same “paths” exist to/from another level. Require a rich supply of “food”: time, energy, RAM…