emergent design: history, concepts, and principles

April 15, 2023 © Agile Institute 2008-2014 1


Emergent Design

History, Concepts, & Principles

Rob MyersAgile Development Practices

East13 November 2014

a definition of emergence


…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


"Termite Cathedral DSC03570”taken by w:User:Yewenyi - [1].Licensed underCreative Commons Attribution-Share Alike 3.0via Wikimedia Commonshttp://commons.wikimedia.org/wiki/

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…


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!



A Brief History ofObject 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();


encapsulation

• Hiding data & implementation, and also design, type, cardinality, construction...

• Hidden from whom or what?

• Why?

• Favor strong encapsulation, but reveal what’s needed.


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?


coupling

• A class or method’s knowledge about another class.

• Good encapsulation reduces coupling.

• Intentional (“good”), and accidental (“bad”).


spot the accidental coupling


// 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?”);

}

April 15, 2023 © 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()


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?


(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?


Testability

• The ability to verify the behaviors of an object.

• How would the following support this?

• Good cohesion.

• Only necessary coupling.

• Less duplication.



Wisdom ofDesign Patterns


Stream

BinaryStream

(Subclassing for Specialization)

CharacterStream

EncryptedCharacterStream CompressedCharacterStream

EncryptedBinaryStreamStream

EncryptedNetworkCharacterStream EncryptedFilesystemCharacterStream


Stream

1. Favor object (instance) delegation over class inheritance

Mode

Binary Character

Device

Network Filesystem

Stream

StreamDecorator

EncryptedStream CompressedStream

PsychicLink


Stream

2. Design to types, not implementations.

Mode

Binary Character

Device

Network Filesystem PsychicLink


Stream

3. Encapsulate any variation.

Mode

Binary Character

Device

Network Filesystem PsychicLink


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


Single Responsibility Principle.

Open-Closed Principle.

Liskov Substitution Principle.

Interface Segregation Principle.

Dependency Inversion Principle.


emergence


Developer’s “Oath of Athens”

I vow to leave the code as

good as I found it,

or better!


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


Relentless Refactoring

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.



[email protected]

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.April 15, 2023 © Agile Institute 2008-2014 43

summary ofemergent 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.


emergent design: history, concepts, and principles

Software

agile institute

emergent design history

emergent design mean

accidental coupling

software design

good encapsulation

simple rules

cohesion good