Real world Evolutionary Design

That's me!

Wassel Alazhar

Developer

@wasselovski

https://github.com/jcraftsman

Agenda

• Warming up
  • Let's get to know each other
  • Setup

• Iteration 1: Micro design 
  • Implementing a requirement
  • Retrospective

• Iteration 2: Macro design
  • Refactoring
  • Retrospective​

• Evolutionary design?

(10 min)

(10 min)​

(20 min)

(30 min)

(10 min)

(30 min)

(10 min)

What do you expect?

You will be happy if ...

2 minutes

Objectives

• Introducing evolutionary design
• Having fun coding together

Playtime

The use case

https://github.com/jcraftsman/evolutionary-design-workshop

Find documents, fast!

Our agents have a high risk job.

They provide us with pictures of the documents we need.

Finding a document by searching for a text it contains is huge amount
of work.

Plug into the existing system

In the intelligence center,
we already have a search engine.

What we need is a tool that analyses the pictures of the documents and notifies the search engine.

The "rules"

But hey...

What is Evolutionary Design?

Let's start by

what it is not!

BIG Upfront Design

• Endless discussions
• Focus on the solution
• Solving the wrong problem
• Speculative development (YAGNI)
• A lot of frustration

No Design

No Design

1. It is messy but it is working (Why fix it if it is not broken!?)
2. We will clean it later (later = never)
3. The mess slows you down

We should take time to go fast (or to just keep moving)

How did we get here?

Gotta get out of this

Evolutionary Design

Software is alive

How to make it evolve in a natural way

Evolutionary Design

• Not a one shot decision
• Continuous and emerging
• Early and often

There will be refactoring!

SIMPLICITY

A delicate balance

SIMPLICITY

FLEXIBILITY

A delicate balance

YAGNI

FLEXIBILITY

Don't think you know!

All non-trivial abstractions, to some degree, are leaky. (*)

1. Identify the axis of changes
2. Then implement the abstractions that will protect you from these changes (e.g. Domain vs Infrastructure)

Abstraction vs Details

(*)The law of leaky abstractions by Joel Spolsky

A delicate balance

DRY

FLEXIBILITY

Don't think you know!

Removing accidental duplication may lead to accidental complexity and break flexibility

Beware of accidental duplication

Don't think you know!

• Incorporate feedback!
• We all have our design bias (OO, FP, CQRS, Microservice, Event, non functional, hexagonal...)
• We are heavily biased towards the vocabulary we are comfortable with

Focus on the problem not the solution

Deductive vs Inductive

General principles

Specific instances

Deductive

Inductive

Deductive vs Inductive

Theory

Confirmation

Deductive

Inductive

Hypothesis

Observation

Observation

Theory

Pattern

Hypothesis

What do you think about deductive approach?

10 minutes

Good for ...

Disadvantages

Not suitable for ...

Advantages

Deductive
Evolutionary Design

• Breakdown of a logic into its parts
• Decomposing complexity
• Deducing abstractions inside a bounded context
• Focus on the interactions
• Collaboration behaviour is important not implementation
• Nothing comes outside the box

Inductive
Evolutionary Design

1. Start from small details
2. Generalize non accidental duplication
3. Evolve small behavior into design concepts
4. Generalize design concepts
5. Evolve design concepts into components

source: http://blog.adrianbolboaca.ro

Inductive
Evolutionary Design

• Scalar => Primitive type (string, int, array)
• Primitive type => Field or parameter
• Field => Settings class
• Parameter => Data structure
• Logic => Pure function
• Pure function => Class function
• Class => Component

Example of incremental design decisions:

source: http://blog.adrianbolboaca.ro

Inductive
Evolutionary Design

• Risk mitigation
• Early validation of requirements
• Behavior is important not implementation
• Focus more on state behavior than the collaboration
• Most Valuable things first

Inductive and Deductive
Evolutionary Design

You don't have to choose

You can use them both

What about architecture

Architecture is a term that lots of people
try to define...
There are two common elements:

1 - The highest-level breakdown of a system
into its parts

2 - Decisions that are hard to change ...

Decisions that developers wish they could get right early...
The subjectivity comes in here as well because, if you find something that is easier to change than you once thought, then it's no longer architectural ...

Source: Patterns of Enterprise Application  Architectue by Martin Fowler

Take away

Forget about the big upfront design, but don't forget to think about design

Evolutionary design is about the decisions that emerge from a living code in order to evolve it and keep mastering its complexity