Generic or Specific? Making Sensible Software Design Decisions
0 likes177 views
The document discusses whether to design software solutions as generic or specific. It outlines different levels at which this decision applies, from code to organization-wide. While generic solutions are more flexible, specific solutions are faster and cheaper to build initially. Tools like the Rule of Three and YAGNI help decide by avoiding premature genericization. The costs of both generic and specific solutions must be weighed based on a project's needs and scope. Conway's Law also notes that organizational structure influences software structure.
Generic or Specific? Making Sensible Software Design Decisions
- 1. Generic or specific? Making sensible software design decisions
- 3. [email protected] Making sensible software design decisions Bert Jan Schrijver @bjschrijver Generic or specific?
- 4. Bert Jan Schrijver L e t ’ s m e e t @bjschrijver
- 5. Levels of generic vs specific Tools to help decide Flexibility in software Definitions When & why to go generic Sharing code in an organization Conclusion Outline W h a t ‘ s n e x t ? The cost of generic @bjschrijver
- 6. What is software design?
- 8. • Tailor made for use in a single place • Tailored to a specific problem or scenario • May not be easily adaptable to other situations Specific solution (or design)
- 9. • More flexible and reusable solution • Solution can be applied to a wide range of problems or scenarios • Generified solution that can be used in more than 1 place Generic solution (or design) Background source: https://filmquarterly.org/2012/07/02/i-robot-what-do-robots-dream-of/
- 10. • Breaking a system or problem into smaller parts that are easier to understand • Example: Google search Hierarchical decomposition Background source: DALL·E
- 12. • Kind and degree of interdependence between building blocks of software • Measure of how closely connected two components are • Usually contrasted with cohesion (low coupling -> high cohesion) Coupling Background source: DALL·E
- 13. • Inheritance • Messages or events • Temporal • Data types • Data • Code / API (binary or source) Types of coupling Background source: DALL·E
- 14. Be careful with coupling!
- 15. Generic solution = coupling!
- 16. The risk of DRY
- 17. Duplicated code doesn’t hurt until you need to change it.
- 18. • Should we be prepared for future changes? • Design should be structured to accommodate change • Risk management: risk of wrong decision “Future proof” design Background source: DALL·E
- 19. About flexibility in software…
- 20. “Highly specific code is often preferable to sophisticated configuration” - Stefan Tilkov
- 21. When are we going to talk about generic vs specific? Background source: https://7216-presscdn-0-76-pagely.netdna-ssl.com/wp-content/uploads/2011/12/confused-man-single-good-men.jpg
- 22. • Code / class level • Manually written vs generated code • Library level • Data level • (Micro)service level • Organisation level Generic vs specific: levels Background source: DALL·E
- 24. • Do we really need this now? (YAGNI) • The 5 W’s • Time/effort for generic vs specific • Myth of “first time right” • Complexity and scope • The rule of three • Future needs and evolution Tools to help decide
- 25. • When reusing code, copy it once, and only abstract the third time • Avoid writing the wrong abstraction • It’s easier to make a good abstraction from duplicated code than to refactor the wrong abstraction • "Three strikes and you refactor" The rule of three Background source: https://learntalk.org/en/blog/where-did-the-saying-third-times-the-charm-come-from
- 26. • First case: Just build it, don’t genericise at all. Solve the problem in front of you (YAGNI) • Second case: Duplicate the original, redesign and extract common behaviour while you change • Third case: examine lessons from first two passes, design a generic solution that will make it easy to add your third case The rule of three Background source: https://learntalk.org/en/blog/where-did-the-saying-third-times-the-charm-come-from
- 27. • Pass 1: YAGNI / rule of three: as simple and specific as possible • Pass 2: based on solution domain knowledge: is a generic solution less work? • Pass 3: based on problem domain knowledge: is the easiest solution actually correct? • Pass 4: looking at customer behaviour or other non technical considerations, does this change your decision? Design heuristics Background source: DALL·E
- 28. • Concept from Domain Driven Design • Tool to help decide for generic vs specific • But more about building yourself or not • Subdomains: • Core domain • Supporting subdomain • Generic subdomain Strategic design Background source: GR Stocks on Unsplash
- 29. • Organizations design systems that mirror their own communication structure • Don’t force a solution that goes against the organisation structure • Be careful to go generic when teams don’t want to work together Conway’s law Background source: DALL·E
- 30. Conway’s law in action Background source: DALL·E
- 31. • Another rule of three: building reusable components is 3x as difficult as single use • The price you pay is coupling • Both on code level and people/team level (communication overhead) The cost of a generic solution Background source: DALL·E
- 32. What if you get it wrong? Photo: Dave Lehl
- 33. • Efficiency gains of a generic solution are typically clear, but how about: • Onboarding new people • Readability • Coupling The cost of abstractions Background source: Héctor J. Rivas on Unsplash
- 34. • Writing bad abstractions • Writing unnecessary reusable code • Introducing unnecessary coupling • Maintaining bad abstractions • Hard to see • Hard to understand • Hard to extend The cost of abstractions Background source: Héctor J. Rivas on Unsplash
- 35. When / why to go generic
- 36. • ”We’ve always done it like this” • “We don’t want to depend on libraries” • “We need to be future proof” • Because the product owner wants it • Because the architect wants it Bad reasons to go generic
- 37. • Rule of three checks out • You’re pretty sure you’re going to need it almost everywhere • A library that lots of teams will use • Complex logic or skills that only a couple of people have • Gains are bigger than cost Valid reasons to go generic
- 38. • Think back about the layers in hierarchical decomposition of a system • Code vs component vs service • Are the considerations for generic vs specific the same on every level? • Risk when getting it wrong is higher when the level is higher • Don’t confuse generification with standardization! Generic vs specific in different scopes Background source: Fernando Gomez on Unsplash
- 39. Why specific is often faster
- 40. Code golf
- 41. Advent of code
- 49. 49
- 50. Generic solutions on organization level
- 51. • Sharing code efficiently at scale is hard • Sharing code at scale means: • Multiple modules that share code • Multiple team members • High rate of change • Little to no loss of individual productivity Sharing code within an organization Source: https://medium.com/@jeffwhelpley/the-problem-with-shared-code-124a20fc3d3b
- 52. • Challenges: • Refactoring • Versioning • Reviewing • Builds and codebase size - monorepo? Sharing code within an organization Source: https://medium.com/@jeffwhelpley/the-problem-with-shared-code-124a20fc3d3b
- 53. • Monorepo: 1 large repository for a group of projects (possible all projects) • Good: easy to make changes across projects • Bad: dependencies & build times Monorepositories Background source: DALL·E
- 54. • Discovery: what code / libraries exist? • Distribution: binary or source dependency? • Import: well defined API’s or chaos? • Versioning, upgrades and lifecycle management • Who maintains it? • Possible approach: inner source culture Considerations on sharing code in an org Source: https://medium.com/@jeffwhelpley/the-problem-with-shared-code-124a20fc3d3b, background source: Klara Kulikova on Unsplash
- 55. Summary
- 56. • Consider: • YAGNI / Rule of three / 5 W’s • Cost of generic • Scope / level • Conway’s law • Organization Generic or specific?
- 57. Generic or specific? It depends.
- 58. A program that works perfectly but is impossible to change will become useless. A program that does not work but is easy to change will become and remain useful continuously. Source: Clean Architecture, Robert C. Martin
- 60. NOW GO KICK SOME ASS!
- 62. Thanks for your time. Got feedback? Tweet it! All pictures belong to their respective authors @bjschrijver