REAL WORLD EVOLUTIONARY DESIGN

Do you struggle to build flexible working software without any big up front design?

Do you have fun with code katas but you feel you need more to tackle real world design problems?

During this session, we will build software following different Evolutionary Design techniques. Thanks to this exercise, we will see how "Outside-in TDD by wishful thinking" can help emerging design and keep us focused on the value we strive to deliver."

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

Transcript

1. Real world Real world Evolutionary Design Evolutionary Design
2. That's me! That's me! Wassel Alazhar Developer https://github.com/jcraftsman @wasselovski
3. Agenda 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)
4. What do you What do you expect? expect? You will be happy if ... 2 minutes
5. Objectives Objectives Introducing evolutionary design Having fun coding together
6. Playtime Playtime The use case https://github.com/jcraftsman/evolutionary-design-workshop
7. The "rules" The "rules"
8. But hey... But hey... What is Evolutionary What is Evolutionary Design? Design?
9. Let's start by Let's start by what it is not! what it is not!
10. BIG BIG Upfront Upfront Design Design Endless discussions Focus on the solution Solving the wrong problem Speculative development (YAGNI) A lot of frustration public class AbstractCommonManagerImpl extends AbstractCommonManager {
11. No Design No Design
12. 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?
13. Gotta get out of this Gotta get out of this
14. Evolutionary Design Evolutionary Design Software is alive How to make it evolve in a natural way
15. Evolutionary Evolutionary Design Design Not a one shot decision Continuous and emerging Early and often There will be refactoring!
16. SIMPLICITY SIMPLICITY
17. A delicate balance A delicate balance SIMPLICITY FLEXIBILITY
18. A delicate balance A delicate balance YAGNI FLEXIBILITY
19. Don't think you know! 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
20. A delicate balance A delicate balance DRY FLEXIBILITY
21. Don't think you know! Don't think you know! Removing accidental duplication may lead to accidental complexity and break flexibility Beware of accidental duplication
22. Don't think you know! 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
23. Deductive vs Inductive Deductive vs Inductive General principles Specific instances Deductive Inductive
24. Deductive vs Inductive Deductive vs Inductive Theory Confirmation Deductive Inductive Hypothesis Observation Observation Theory Pattern Hypothesis
25. What do you What do you think about think about deductive deductive approach? approach? 10 minutes Good for ... Disadvantages Not suitable for ... Advantages
26. Deductive Deductive Evolutionary Design 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
27. Inductive Inductive Evolutionary Design 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
28. Inductive Inductive Evolutionary Design 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
29. Inductive Inductive Evolutionary Design 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
30. Inductive and Deductive Inductive and Deductive Evolutionary Design Evolutionary Design You don't have to choose You can use them both
31. What about What about architecture 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
32. Take away 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