Reversible Decisions for Better Software Design (VoxxedDays Zürich)

Transcript

1. @dtanzer@social.devteams.at - @dtanzer.bsky.social Reversible Decisions For Better Software Design David Tanzer (business@davidtanzer.net) 1
2. Today • Easy to Change vs. Hard to Change • Design Decisions to Make Changes Easier • MMMSS • Feedback • Refactoring • What about AI? @dtanzer@social.devteams.at - @dtanzer.bsky.social 2
3. Non-Solution: Branching It just delays the point at which you have to deal with the problem! @dtanzer@social.devteams.at - @dtanzer.bsky.social 3
4. • A Spectrum of Decisions • Why are Things Hard to Change? • Reversible Structure Changes @dtanzer@social.devteams.at - @dtanzer.bsky.social Easy to Change vs. Hard to Change 4
5. A Spectrum of Decisions @dtanzer@social.devteams.at - @dtanzer.bsky.social 5
6. @dtanzer@social.devteams.at - @dtanzer.bsky.social 6
7. @dtanzer@social.devteams.at - @dtanzer.bsky.social 7
8. @dtanzer@social.devteams.at - @dtanzer.bsky.social 8
9. @dtanzer@social.devteams.at - @dtanzer.bsky.social 9
10. Why are Things Hard to Change? • Changes break functionality • Multiple changes in different parts of the code required • Every change requires more changes • Coupling ◦ But: Can we prevent all coupling? @dtanzer@social.devteams.at - @dtanzer.bsky.social 10
11. Reversible Structure Changes • Haircut vs. Tattoo ◦ vs. cutting your arm off! • In general, we should treat reversible decisions differently than irreversible decisions --Kent Beck, "Tidy First", p. 75 @dtanzer@social.devteams.at - @dtanzer.bsky.social 11
12. Reversible Structure Changes When changes are reversible (and quick to implement), we can just try to make them without planning or thinking too much! @dtanzer@social.devteams.at - @dtanzer.bsky.social 12
13. Two Cases • Change a decision that was already made ◦ First, make the change easy, then make the easy change (Kent Beck) • Implement a decision you might need to change later ◦ Any decision! ◦ Can you make future changes easier? @dtanzer@social.devteams.at - @dtanzer.bsky.social 13
14. • Coupling and Cohesion • Inside vs. Outside • Contain the Damage • SOLID / CUPID • Techniques fom DDD • Attractive Code • Options • Feature Flags @dtanzer@social.devteams.at - @dtanzer.bsky.social Design Decisions to Make Changes Easier 14
15. Coupling and Cohesion • to couple: to join or combine • In software development coupling is the degree of interdependence between software modules • to cohere: to unite or to hold together as a unit • In software development: cohesion refers to the degree to which the elements inside a module belong together @dtanzer@social.devteams.at - @dtanzer.bsky.social 15
16. Inside vs. Outside @dtanzer@social.devteams.at - @dtanzer.bsky.social 16
17. @dtanzer@social.devteams.at - @dtanzer.bsky.social 17
18. @dtanzer@social.devteams.at - @dtanzer.bsky.social 18
19. @dtanzer@social.devteams.at - @dtanzer.bsky.social 19
20. @dtanzer@social.devteams.at - @dtanzer.bsky.social 20
21. @dtanzer@social.devteams.at - @dtanzer.bsky.social 21
22. Universal Architecture • Happy zone: In-memory, fast, domain-driven, no concurrency, ... • DMZ translates and protects • Interfaces to happy zone are well-designed ◦ AND are part of the happy zone • Keep DMZ as thin as possible • Code flows from DMZ to happy zone • cf. Ports and adapters, onion architecture, clean architecture J.B. Rainsberger @dtanzer@social.devteams.at - @dtanzer.bsky.social 22
23. Contain the Damage @dtanzer@social.devteams.at - @dtanzer.bsky.social 23
24. @dtanzer@social.devteams.at - @dtanzer.bsky.social 24
25. @dtanzer@social.devteams.at - @dtanzer.bsky.social 25
26. @dtanzer@social.devteams.at - @dtanzer.bsky.social 26
27. @dtanzer@social.devteams.at - @dtanzer.bsky.social 27
28. Contain the Damage • Define interfaces that are error boundaries ◦ Validate all data going across ◦ Do not pass on errors ◦ cf. Circuit breaker pattern • Define interfaces that stop code ripples ◦ Beware of shared code or data structures here • Micro services or modular monoliths • cf. "Breakwater Technique" by GeePaw Hill @dtanzer@social.devteams.at - @dtanzer.bsky.social 28
29. SOLID • Single Responsibility Principle • Open / Closed Principle • Liskov Substitution Principle • Interface Segregation Principle • Dependency Inversion Principle Robert C. Martin CUPID • Composable • Unix Philosophy • Predictable • Idiomatic • Domain-based Daniel Terhorst-North @dtanzer@social.devteams.at - @dtanzer.bsky.social 29
30. Attractive Code When I introduce a ValueObject, I expect it to become "attractive code", meaning literally a class/module that attracts behavior towards it as new methods/functions. --J.B. Rainsberger @dtanzer@social.devteams.at - @dtanzer.bsky.social 30
31. Techniques fom DDD • Bounded Context • Relationship between contexts ◦ Equal ◦ Upstream / Downstream ◦ Separate Ways • Open Host Service vs. Consumer Driven Contracts • Contain the damage ◦ Anti Corruption Layer @dtanzer@social.devteams.at - @dtanzer.bsky.social 31
32. Options Anything you can do without the obligation to do it is a real option. --Maassen/Matts/Geary, "Commitment", p. 59 • Options have value ◦ The value of the benefit ◦ AND the value of the fact that you can still decide • Options expire • Never commit early unless you know why @dtanzer@social.devteams.at - @dtanzer.bsky.social 32
33. Feature Flags Keep the old version, implement change as new feature. @dtanzer@social.devteams.at - @dtanzer.bsky.social 33
34. • The Sortest Distance • Intrinsic Benefit of Steps • Reversibility of a Step vs. the Chain • How to Apply @dtanzer@social.devteams.at - @dtanzer.bsky.social MMMSS 34
35. @dtanzer@social.devteams.at - @dtanzer.bsky.social 35
36. @dtanzer@social.devteams.at - @dtanzer.bsky.social 36
37. @dtanzer@social.devteams.at - @dtanzer.bsky.social 37
38. @dtanzer@social.devteams.at - @dtanzer.bsky.social 38
39. @dtanzer@social.devteams.at - @dtanzer.bsky.social 39
40. The Sortest Distance In software engineering, it's usually not a straight line! • You can only find the real path by taking small steps ◦ and getting feedback ◦ and adjusting @dtanzer@social.devteams.at - @dtanzer.bsky.social 40
41. Intrinsic Benefit of Steps • Steerability • Interruptability • Reversibility • ...others... GeePaw Hill, Intrinsic Benefits of Steps • Faster feedback = more value, sooner @dtanzer@social.devteams.at - @dtanzer.bsky.social 41
42. Reversibility of a Step vs. the Chain @dtanzer@social.devteams.at - @dtanzer.bsky.social 42
43. How to Apply • Work in small steps • Get feedback, adjust • Keep the chain reversible @dtanzer@social.devteams.at - @dtanzer.bsky.social 43
44. • Contain the Damage! • Getting Feedback Faster • Static Analysis • TDD • Approval Tests @dtanzer@social.devteams.at - @dtanzer.bsky.social Feedback 44
45. Contain the Damage! Feedback helps to contain the damage in the time dimension. Find out sooner when you have to reverse a change. @dtanzer@social.devteams.at - @dtanzer.bsky.social 45
46. Getting Feedback Faster • Observability • Automation • Smaller steps • ... @dtanzer@social.devteams.at - @dtanzer.bsky.social 46
47. Static Analysis @dtanzer@social.devteams.at - @dtanzer.bsky.social 47
48. TDD @dtanzer@social.devteams.at - @dtanzer.bsky.social 48
49. @dtanzer@social.devteams.at - @dtanzer.bsky.social 49
50. @dtanzer@social.devteams.at - @dtanzer.bsky.social 50
51. @dtanzer@social.devteams.at - @dtanzer.bsky.social 51
52. TDD How does that help with reversible decisions? • Tests as safety net • Tests as thinking aid • Tests that verify safe interfaces • Further risk reduction: BDD, Double-Loop TDD, Agile Acceptance Testing, ... @dtanzer@social.devteams.at - @dtanzer.bsky.social 52
53. Approval Tests • Automate some action in the system under test • Record the results • Test fails if results changed ◦ Manually accept or reject new result @dtanzer@social.devteams.at - @dtanzer.bsky.social 53
54. • What is It / What Not? • Series of Safe Steps: MMMSS • Confidence: No Behavior Change • How does That Help? @dtanzer@social.devteams.at - @dtanzer.bsky.social Refactoring 54
55. What is It / What Not? A change made to the internal structure of the software to make it easier to understand and cheaper to modify without changing its observable behavior -- Martin Fowler • Feature-for-feature and bug-for-bug compatible • How can we know we have not changed anything? @dtanzer@social.devteams.at - @dtanzer.bsky.social 55
56. Series of Safe Steps: MMMSS • Many small changes • Automate as much as possible • Use provable refactoring • Validate every step @dtanzer@social.devteams.at - @dtanzer.bsky.social 56
57. Confidence: No Behavior Change • Feature-for-feature and bug-for-bug compatible @dtanzer@social.devteams.at - @dtanzer.bsky.social 57
58. How does That Help? • Getting better at refactoring enables reversible decisions • Refactoring is a skill ◦ Can be learned ◦ Needs to be practiced @dtanzer@social.devteams.at - @dtanzer.bsky.social 58
59. • Tragedy of the Commons • How can AI help? • Refactoring with AI • How does AI benefit? @dtanzer@social.devteams.at - @dtanzer.bsky.social What about AI? 59
60. Tragedy of the Commons (not really) • (Unpopular?) Opinion: AI is a net negative for humanity. • -but- • Not using it comes with risks and drawbacks ◦ Especially if you are the only one not using it • Using it is probably unethical • Not using it is probably unethical too https://en.wikipedia.org/wiki/Tragedy_of_the_commons @dtanzer@social.devteams.at - @dtanzer.bsky.social 60
61. How can AI help? • Very good at reviewing the impact of a change ◦ "Did this code change alter behavior?" ◦ "Did this code change impact performance?" • Good at analyzing code ◦ Architecture / Design ◦ Code Smells • OK / Not completely bad at coming up with a series of small steps @dtanzer@social.devteams.at - @dtanzer.bsky.social 61
62. Refactoring with AI • AI does not refactor ◦ At least not what we considered refactoring in the past • May introduce side effects (seldom, nowadays) • Often creates big changes that are hard to review • Valuable tool if you use it with guard rails @dtanzer@social.devteams.at - @dtanzer.bsky.social 62
63. How does AI benefit? • Low coupling / high cohesion keeps context small • Automated safety nets help validate AI results • Small steps make human review easier • -> What helps us make decision reversible also makes it easier to work with AI @dtanzer@social.devteams.at - @dtanzer.bsky.social 63
64. • Easy to Change vs. Hard to Change • Design Decisions to Make Changes Easier • MMMSS • Feedback • Practice Refactoring • AI Benefits and Can Help @dtanzer@social.devteams.at - @dtanzer.bsky.social Conclusions 64
65. A Spectrum of Decisions @dtanzer@social.devteams.at - @dtanzer.bsky.social 65
66. David Tanzer • Freelancer since 2006 • Software developer / Architect • Trainer and Technical Coach ◦ Agile Engineering ◦ Modern Software Engineering • davidtanzer.net - devteams.at • business@davidtanzer.net • https://social.devteams.at/@dtanzer • https://bsky.app/profile/dtanzer.bsky.social @dtanzer@social.devteams.at - @dtanzer.bsky.social 66