When designing software we can start from the high-level concepts and then dive into the details or we can start from the small details and try to understand the higher-level concepts. London School TDD and Domain Driven Design typically approach design from a deductive point of view. Classicist (Chicago School TDD) typically approach design from an inductive point of view. Both of them are powerful, but in specific context. Each of them has drawbacks in some situations. Let's practice, discuss and learn when it is a better idea to be inductive or deductive. Which Evolutionary Design tools to use so we can reach faster to a small easy to change software system that solves the business needs.

1. blog.adrianbolboaca.ro mozaicworks.com
Evolutionary Design:
Inductive and Deductive
Adrian Bolboacă
@adibolb
adrian.bolboaca@mozaicworks.
com

2. blog.adrianbolboaca.ro mozaicworks.com
Agenda
1.Objectives
2.Evolutionary Design
3.Inductive Evolutionary Design + coding
4.Deductive Evolutionary Design + coding
5.Deductive vs Inductive + discussion
6.Evolutionary Design Ideas
7.Conclusions & Retrospective

3. blog.adrianbolboaca.ro mozaicworks.com
Objectives
◊
Understand two opposite ways of designing
your software
◊
Learn when more suitable to be deductive and
when inductive
◊
Patterns and anti-patterns of Evolutionary
Design

4. blog.adrianbolboaca.ro mozaicworks.com
Help me out
1.Do you practice TDD?
2.(if yes) How long have you used TDD?

5. blog.adrianbolboaca.ro mozaicworks.com
Evolutionary Design
The art of growing a system by observing its
natural traits and then normalizing and
optimizing its growth

6. blog.adrianbolboaca.ro mozaicworks.com
Evolutionary Design
Evolutionary design is about the
transformations that take place when we add
new behaviors / tests.

7. blog.adrianbolboaca.ro mozaicworks.com
Inductive
Inductive reasoning makes broad
generalizations from specific observations.
Basically, there is data, then conclusions are
drawn from the data. This is called inductive
logic, according to Utah State University.

8. blog.adrianbolboaca.ro mozaicworks.com
Inductive Evolutionary Design
◊
Focus more on state behavior and less on
collaboration (interaction) behavior
ҩ Start with primitives
ҩ Test the logic of changing state
◊
Collaboration behavior is interesting just at the
limit of the system

9. blog.adrianbolboaca.ro mozaicworks.com
Inductive Evolutionary Design
1.Start from small details
a.Choose an entry point
b.Use Behavior Slicing to analyze the behaviors
c.Order the behaviors from simple to complex
2.Generalize the duplicated behaviors
a.Minimize non-accidental duplication in the code
b.Maximize the clarity of the concepts

10. blog.adrianbolboaca.ro mozaicworks.com
Inductive Evolutionary Design
3. Evolve small behaviors into design concepts
a.Move similar behavior in the same place
b.Maximize clarity of the moved behaviors
2.Generalize the design concepts
a.Use composition (or rarely inheritance)
b.Use Dependency Inversion to have a logical dependency
graph
3.Evolve the design concepts into components
a.Modules
b.Bounded contexts

11. blog.adrianbolboaca.ro mozaicworks.com
Inductive Design Characteristics
◊
Behavior is important, not implementation
◊
Representation doesn’t matter in the beginning
◊
Tests are generalized while duplication is
minimized
◊
Tests start by using primitives and end by
using design concepts
◊
The representation can be changed and the
tests should pass

12. blog.adrianbolboaca.ro mozaicworks.com
Inductive Evolutionary Design
A short coding demo

13. blog.adrianbolboaca.ro mozaicworks.com
Inductive Design Layers
We start with primitives and we evolve the
design in successive layers:
ҩ Scalar Primitive type (string, int, array, etc)→
ҩ Primitive type Field OR Parameter→
ҩ Field Settings Class→
ҩ Parameter Data Structure→
ҩ Logic Pure function→
ҩ Pure function Class function→
ҩ Class Component→

14. blog.adrianbolboaca.ro mozaicworks.com
Inductive Evolutionary Design
◊
Applies to:
ҩ Classicist state-based testing (Chicago School)
ҩ Bottom-up
ҩ Detailed micro-design (TDD As if you Meant It)

15. blog.adrianbolboaca.ro mozaicworks.com
Deductive
Deduction, starts out with a general statement,
or hypothesis, and examines the possibilities to
reach a specific, logical conclusion, according
to the University of California

16. blog.adrianbolboaca.ro mozaicworks.com
Deductive Evolutionary Design
◊
Focus more on collaboration (interaction)
behavior
◊
Create a scaffolding
ҩ Guiding Test
ҩ Bounded Context with business entities
ҩ Walking Skeleton
◊
Deduce the design concepts depending on the
scaffolding

17. blog.adrianbolboaca.ro mozaicworks.com
Deductive Evolutionary Design
1.Start from the scaffolding
a.Identify the entry point
b.Find the next layer of collaboration (interaction)
c.Check the collaboration behavior between the entry point
and the next layer
2.Move deeper to the next layer of collaboration
(interaction)
a.Find the next layer of collaboration (interaction)
b.Check the collaboration behavior between the entry point
and the next layer

18. blog.adrianbolboaca.ro mozaicworks.com
Deductive Evolutionary Design
3.Iteratively understand if you reached the end
a.Use guiding test
b.Have an acceptance test
2.Refactor the design concepts
a.Not having single responsibility
b.Being scattered across the system
c.That are unclear (purpose, naming, etc)

19. blog.adrianbolboaca.ro mozaicworks.com
Deductive Design Characteristics
◊
Behavior is important, not implementation
◊
Representation needs to be addressed minimally
◊
Tests are generic from the beginning
◊
Tests start by using design concepts
◊
The representation can be changed and the tests should pass
◊
The links between the design concepts is essential and made
through their APIs and collaborators
◊
If collaboration behavior changes, the tests make refactoring difficult

20. blog.adrianbolboaca.ro mozaicworks.com
Deductive Evolutionary Design
A short coding demo

21. blog.adrianbolboaca.ro mozaicworks.com
Deductive Evolutionary Design
◊
Applies to:
ҩ Outside-in (London School)
ҩ Middle-top
ҩ Middle-bottom
ҩ Domain Driven Design (DDD)
ҩ Acceptance Test Driven Development (ATDD)

22. blog.adrianbolboaca.ro mozaicworks.com
Deductive vs Inductive
◊
When to use each?
◊
Can they be used in the same time?
◊
Are specific cases when one is more useful
than the other?
◊

23. blog.adrianbolboaca.ro mozaicworks.com
Evolutionary Design Ideas
◊
The tests are pressure applied to existing design
◊
The production code is like clay that gets molded
depending on the pressure applied to it
◊
When evolving the design of a system we observe growth
patterns that simplify the resulting system
◊
Evolutionary Design is like helping your plants grow,
knowing what measures to take so they will be fruitful

24. blog.adrianbolboaca.ro mozaicworks.com
Anti-Patterns
◊
Focus on implementation details and not on
design concepts
◊
Consider that tests are the essential output of
TDD, and not well structured design elements
◊
Consider you know exactly the resulting
design, and don’t listen to the design smells
◊
Focus on the solution and not on the problem

25. blog.adrianbolboaca.ro mozaicworks.com
What’s Next?
◊
Experiment both Deductive and Inductive
approaches during katas or coderetreats
◊
Try both Deductive and Inductive approaches
in your production environment
◊
Watch my codecasts on TDD as if you Meant It
& more
blog.adrianbolboaca.ro/evolutionary-design
◊
Pair with many people and learn from them

26. blog.adrianbolboaca.ro mozaicworks.com
#RemotePairProgramming
Join my #RemotePairProgramming Codecasts:
contact me and pair during a recorded
codecast with me

27. blog.adrianbolboaca.ro mozaicworks.com
Thank you!