Download to read offline
More Related Content
Similar to The Fundamentals of Continuous Software Design
The Fundamentals of Continuous Software Design
- 1. The Fundamentals ofContinuous Software Design May 9th, 2020
- 2. About Me • SeniorArchitect at Calavista Software • (Mostly) Agile since 2003 • http://jeremydmiller.com • shadetreedeveloper@gmail.com • @jeremydmiller
- 3.
- 4.
- 5. DeliveringValue WORKING SOFTWARE BUILDINGFEATURES BY BUSINESS PRIORITY CONTINUOUS DELIVERY
- 6. Between Scylla andCharybdis Big Design Upfront (BDUF) No Upfront Design
- 7. What is ContinuousDesign? • Roots in Extreme Programming • “Evolutionary” or “Emergent” Design • Requires a High Degree of Discipline • Reacting to Feedback
- 8. Design Goals • Don’tRepeat Yourself • Explicit • Simple • Cohesive • Decoupled • Isolated • In the present
- 9. Pull vs Push •Build it and they will come • “You aren’t going to need it” – YAGNI • Do the Simplest Thing That Could Possibly Work
- 10. The Last ResponsibleMoment Make decisions as late as you can responsibly wait because that is the point at which you have the most information on which to base the decision.
- 11. Reversibility “If you caneasily change your decisions, this means it’s less important to get them right – which makes your life much simpler. ” Martin Fowler
- 12. Low Reversibility Plumbing througha slab foundation of a house under construction
- 13. Examples of LowReversibility • Dependencies on External Organizations • Choosing Client Technologies • Basic Code Organization Strategies • Programming Languages • Architectural Patterns
- 14. Examples of HighReversibility • ASP.Net Core Middleware (The Russian Doll Model) • Document Databases • Effective Automated Test Coverage • Modular Code
- 15. Testability andTDD/BDD • EnablesRefactoring • Feedback • Improves Reversibility • Heuristic to improve the low-level design of your code
- 16. “Jeremy’s Laws ofTDDDesign” • Isolate the Ugly Stuff • Push, Don’t Pull • Test Small Before Testing Big • Avoid a Long Tail
- 17. Refactoring A disciplined techniquefor restructuring an existing body of code, altering its internal structure without changing its external behavior Lies, damn lies, and “it’s just going to be some refactoring”
- 18. Bottom Up vsTopDown Design Avoid being frozen by the fear of what you don’t yet know Bottom Up start with individual tasks and assemble the coded elements later as a structure presents itself Top Down start with the basic workflow, leave placeholders for individual steps later
- 19. Spike • “A verysimple program to explore potential solutions” • Quick and dirty prototyping • Throwaway the code
- 20. Process Stuff • Constantlychallenge the design • Always be thinking • Socialize the design • Every developer contributes
- 21.
Editor's Notes
- #2 Heuristics, no prescriptive guidance. All about thinking through problems
- #4 ”Get off my lawn!” Extreme Programming might have been a good thing going, but Scrum swept in. The potential problem with Scrum is that it focuses almost completely on projection management. “Agile” became associated with performative ceremonies like daily standup meetings, sprint reviews, and sprint planning
- #5 ”Get off my lawn!” Extreme Programming might have been a good thing going, but Scrum swept in. The potential problem with Scrum is that it focuses almost completely on projection management. “Agile” became associated with performative ceremonies like daily standup meetings, sprint reviews, and sprint planning
- #6 What’s important is your ability to continuously work on business priorities. Eliminates the possibility of upfront architecture phases or sprints. Puts a lot of stress on technical teams to deliver functionality and initial architectural work upfront. Requires us to put off structural elements for later. Puts an onus on the code structure to allow for later extension without too much rework. Talk about being late and having the entire database and data layer constructed, vs being late but having half the features completely deployable. Talk about the construction metaphor
- #7 Worst failures
- #8 Deciding when to decide, reacting to feedback. Requires a lot of feedback cycles, and there’s what XP really was