The document discusses effective design strategies, including: - Planning backwards from adding straightforward features and moving in safe steps such as refactoring to isolate changes and make progress even when the end goal is unclear. - Migrating to a new design by first moving individual uses, then deleting the old design in parallel or sequentially. Simplifying by eliminating constraints or reducing needs to special cases can also help progress but risks ignoring important factors. - Creating "stepping stones" like frameworks to make the path to a new design easier, though there are costs to consider for extra functionality and maintenance.

1. Effective Design
Kent Beck
Three Rivers Institute

2. Economics
• Time value of money

3. Unknowns
• Needs
• Means
• Cost
• Usefulness

4. Design is Social
• Experience
• Distribution

5. Theory
• Beneficially relating elements
• Cost driver: rippling changes
– Coupling
– Cohesion
• Scale-free
– Fractal

6. Process
Straightforward?
yes no
Add Feature
Isolate Change
Refactor Create

7. Create
• Principle: safe steps
– Going back is expensive
• Leap
• Parallel
• Migrate Old design New design
• Simplify
• Place Stepping Stone

8. Leap
1. Make new design
2. Move all uses
3. Delete old design
+ Quick
- Risk of it not working for large changes

9. Parallel
1. Make new design
+ Quick
+ Safe—doesn’t disturb existing uses
+ Often used in framework evolution
- Costly to maintain two designs
- Need to figure out how to have them
both run

10. Migrate
1. Move a use
+ Quick (per migration)
+ Provides feedback for new design
+ Low risk
- Costly to migrate many uses

11. Simplify
• Eliminate constraints
• Reduce needs
– One, not many
– Few, not many
– Special case, not general
+ Quick
+ Safe
- What if it isn’t really progress?
- What if you ignore the wrong constraint?

12. Place Stepping Stone
1. Build a language (framework) in which getting
to the new design is easier
+ Quicker
- What if it doesn’t make the new design easier?
- Every extra bit is expensive for uses and
maintainers
- Responsibility of language designers and
implementors is much broader than application
developers (build, debug, analyze)

13. Refactorings
- Isolate changes
- Extract/Inline method/object
- Eliminate/introduce duplication
- Eliminate/introduce abstraction/indirection
- Interface
- Superclass
- Move method
- Move field

14. Conclusion
• Plan backwards from adding
straightforward features
• Move in safe steps
• Make progress when you can’t see the
end
• If you can’t make progress, add the
feature anyway