Evolutionary Design: “The art of growing a system by observing its naturaltraits and then normalizing and optimizing its growth” Evolutionary Design seems to be one of the black arts of software development. Evolution = transformation Evolving the code is not done by magic, we the programmers evolve the code,. And we need specific techniques for that. When we evolve, we transform the code to something else. We will talk about some of these transformations, when to use each one and why. Simplicity We work feature by feature and not layer by layer. All the development is done on a vertical thin slice through all the layers. We use evolutionary refactoring with many design principles in our mind, but not with a predefined design. We respect the principles, but focus on finding the simplest solution for the problem. Focus on the problem, not the solution We want to rather focus on the problem and not the solution, rather than when we know the solution, but we just find the fastest way to implement it. When we know the solution, the question is: can it be improved; is it worth it? We will talk about some heuristics of “good enough”. This talk will be an interactive one, presenting some of the most useful techniques for Evolutionary Design.

1. Evolutionary
Design
Adrian Bolboacă
Programmer, trainer, coach
blog.adrianbolboaca.ro
Aythor of the Coderetreat Book
https://leanpub.com/coderetreat

2. Why this talk?
● Continuously improve our understanding of the world
● Push the bar of software development
● Develop living systems, rather than rigid projects
● Evolve rather than change
● Research new ways of developing software

3. Disclaimer
● All ideas presented are in evolution (or in progress)
● This is not a basic talk
● I love philosophy and abstract thinking
● Please ask questions whenever you like

4. What I learned to get
Evolutionary Design
● Unit Testing
● Design Patterns, and how to use them
● The Four Elements of Simple Design
● Pairing
● Team collaboration
● Test Driven Design (TDD)
● TDD Schools: Chicago, London, DDD, etc
● Behavior Driven Development
● Business Analysis
● Domain Driven Design
● Automated acceptance testing
● Exploratory Testing
● … and much more

5. Contents
1) Evolutionary Design Defnition
2) Evolution
3) Simplicity
4) Focus on problem, not solution
5) Theory of Centers
6) Symmathesy
7) Solution Navigation
8) Transformations

6. 1) Evolutionary Design
Evolutionary = heritable characteristics over
successive generations
Design = building useful objects for specifc
needs
So: how to build objects that continuously
change, but keep its existing functions intact

7. 1) Evolutionary Design
“The art of growing a system by observing its
natural traits and then normalizing, optimizing
and maximizing its growth”
Adrian Bolboaca

8. Why Evolutionary
Design?
● Build systems that are resilient to change
● Adapt your pace to the business needs
● Manage growing complexity

9. a. Normalizing Growth
● Observe irregular developments
● Refactor system’s growth to normalize it
● Balance system’s growth
● Setup practices and guidelines
● Create standards of growth

10. b. Optimize Growth
● Choose a growth objective
● You cannot optimize for everything
● Compromise
● Focus on business needs
● Observe, pro-act, re-act

11. c. Maximizing Growth
● Make the most out of each optimization
● Understand when it’s the “fertile” moment
● Observe patterns like Low Coupling,
High Cohesion, Structural Duplication, etc
● Use coherent strategies

13. 2) Evolution
Behavior Slicing
● Identify your evolution focus
● Look at Outputs
● Find corresponding inputs
● Organize from simple to complex
Many thanks to Alex Bolboaca

14. 3) Simplicity
The art of fnding the simplest options
● Evolve to the simplest solution you can
● Remove rather than add items to the system
● Use The 4 Elements of Simple Design
● Use Behavior Slicing
● The simplest solutions are natural ones

15. 4) Focus on problem,
not on solution
Test After – solution focus
Design Code Test→ →
Test First Programming – solution focus
Design Test Code→ →
Test Driven Design – problem focus
Test Code Design→ → → Solution evolves

16. 5) Theory of Centers
A bottom-up approach, which places users
of buildings as builders of their environments
through the process of co-creating a
common ground with the collective consensus
of a “shared pattern language”; to give users
better control over the spaces they dwell in.
from Christopher Alexander
https://nourdiab.wordpress.com/2011/02/23/the-theories-of-christo
pher-alexander

17. 5) Theory of Centers
● Observe system’s behavior
● Find similarities and particularities in
decentralized systems
● Identify hubs around which systems
occur in living structures
from Christopher Alexander
Many thanks to Emmanuel Gaillot

18. 6) Symmathesy
Symmathesy = Mutual Learning in Living
Systems
A word in progress
from Nora Bateson
https://norabateson.wordpress.com/2015/11/03/symmathesy-a-word-in-progress
Many thanks to Jessica Kerr

19. 6) Symmathesy
For Evolutionary Design
● Feedback is a learning mechanism
● The designer uses techniques to learn
from the software system
● Identify patterns and heuristics (similarities,
duplication, coherence, etc)
● Maybe in the future the system might be
able to learn from the designer

20. 7) Solution Navigation
Navigation-related structural change in the
hippocampi of taxi drivers.
“The role of the hippocampus is to facilitate
spatial memory, in the form of navigation”
https://www.tutor2u.net/psychology/reference/maguire-2000
Many thanks to https://twitter.com/sleepyfox

21. 7) Solution Navigation
● Practice to identify possible solutions
(Solution Seeker
http://blog.adrianbolboaca.ro/2014/02/pair-programming-game-solution-seeker )
● Pair with experienced navigators
● Extend your comfort zone for heuristics
● Work on design studies
● Read a lot of code
● Choose possible solutions based on
objective factors
● Feed your brain with practice

22. 8) Transformations
During an evolution, transformations are the
essence:
● Transformation Priority Premise
● Levels of Abstraction
● Levels of Coupling
● Inductive vs Deductive
● ...

23. 8) Transformations
But how do we have transformations?
We put pressure on existing design
Tests are pressure on existing design. We
need to look at the patterns and evolve the
system organically
Tests are not the only type of pressure

24. 8) Transformations
Transformation Priority Premise
“As the tests get more specifc, the code gets
more generic.”
from Robert C Martin
https://8thlight.com/blog/uncle-bob/2013/05/27/TheTransformationPriorityPremise.html

25. 8) Transformations
Transformation Priority Premise
● ({}–>nil) no code at all->code that employs nil
● (nil->constant)
● (constant->constant+) a simple constant to a more complex constant
● (constant->scalar) replacing a constant with a variable or an argument
● (statement->statements) adding more unconditional statements.
● (unconditional->if) splitting the execution path
● (scalar->array)
● (array->container)
● (statement->recursion)
● (if->while)
● (expression->function) replacing an expression with a function or algorithm
● (variable->assignment) replacing the value of a variable.

26. 8) Transformations
Levels of abstraction
Depending on which abstraction level you want to
evolve the system, you might use diferent heuristics
Use encapsulation to abstract communication
between levels
● complex systems
● system
● subsystem
● module
● (optional) namespace / package
● interface / superclass
● class / enum / struct
● feld / constant
● variable
● value

27. 8) Transformations
Levels of Coupling
Depending on the coupling your system can evolve
naturally more or less
● Conventions
● Transient
● Events
● Composition
● Inheritance
● Class scope
● Function scope

28. Inductive vs Deductive
Inductive
● Start from the atomic part and refactor++.
● Use refactoring heuristics to normalize
growth
● No design up-front
Deductive
● Start from scafolding
● Use heuristics to optimize growth
● More design up-front

29. Inductive vs Deductive
Inductive (usually)
● TDD as if you Meant It
● Bottom-up
● Take few decisions at a time
● Middle-top (DDD)
Deductive (usually)
● Walking Skeleton
● Outside-in
● Take structural decisions
● Middle-bottom (DDD)

30. Inductive vs Deductive
I had a very long talk in Paris Oct 2017
about Inductive vs Deductive Evolutionary
Design
Read at
https://medium.com/@cyrillemartraire/adrian-bolboaca-on-evoluti
onary-design-inductive-vs-deductive-approaches-a7cead4bdd20
Thanks to Cyrille Martraire for the write-up

31. Selection Pressure
● Pressure = business metrics
● Use business tests to grow your system
● Similar with TDD as if you Meant It, but with
business focus
Many thanks to Julian Ghionoiu
Code cast
http://blog.adrianbolboaca.ro/2018/01/remotepairprogramming-ep-005
-evolutionary-design-selection-pressure

32. Recap
1) Evolutionary Design Defnition
2) Evolution
3) Simplicity
4) Focus on problem, not solution
5) Theory of Centers
6) Symmathesy
7) Solution Navigation
8) Transformations

33. What’s Next for me?
Evolve the topic
Write more articles
Publish more code casts
Write a book on Evolutionary Design

34. What’s Next for you?
Let’s talk about this topic
(Continuously Evolving) series of articles
and code casts
http://blog.adrianbolboaca.ro/evolutionary-design
Remote Pair with me
http://blog.adrianbolboaca.ro
Share your experiences
https://twitter.com/adibolb

35. About me
When not thinking about philosophical
topics I still:
Write software
Help companies and teams
Mentor, train and coach

36. Workshop
Join Evolutionary Design Workshop
25-26 June in Paris
https://mozaicworks.com/public-trainings-and-workshops/evolutionary-de
sign-workshop

37. Mozaic Works Design
School
Join the Mozaic Works Design School
How? Contact me!

38. Contact me
Adrian Bolboacă
Programmer, trainer, coach
adrian.bolboaca@mozaicworks.com
@adibolb