Generic or Specific? Making sensible software design decisions
0 likes•44 views
Presented at DevBcn 2025
Generic or Specific? Making sensible software design decisions
- 1. [email protected] Making sensible software design decisions Bert Jan Schrijver Generic or specific? @bjschrijver.dev
- 2. Bert Jan Schrijver L e t ’ s m e e t @bjschrijver.dev
- 3. @bjschrijver.dev Levels of generic vs specific Tools to help decide Flexibility in software Definitions When & why to go generic Bonus: sharing code in an organisation Conclusion Outline W h a t ‘ s n e x t ? The cost of generic
- 4. What is software design?
- 6. • 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)
- 7. • Flexible and reusable solution • Can be applied to a wide range of problems or scenarios • Generified solution that can be used in more than 1 place • In this talk: generic = shared code Generic solution (or design) Background source: https://filmquarterly.org/2012/07/02/i-robot-what-do-robots-dream-of/
- 8. • Breaking a system or problem into smaller parts that are easier to understand • Example: Google search Hierarchical decomposition Background source: DALL·E
- 10. • 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
- 11. • Inheritance • Messages or events • Temporal • Data types • Data • Code / API (binary or source) Types of coupling Background source: DALL·E
- 12. Be careful with coupling!
- 13. Generic solution = coupling!
- 14. The risk of DRY
- 15. Duplicated code doesn’t hurt until you need to change it.
- 16. • 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
- 17. 17
- 18. About flexibility in software…
- 19. “Highly specific code is often preferable to sophisticated configuration” - Stefan Tilkov
- 20. 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
- 21. • Code / class level • Manually written vs generated code • Library level • Data level (or data structure level) • (Micro)service level • Organisation level Generic vs specific: levels Background source: DALL·E
- 23. • When you make something generic, you’re making an abstraction • An abstraction generalizes over the problem and solution space by finding common behaviour and hiding implementation details Abstractions Background source: Héctor J. Rivas on Unsplash
- 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. • Concept from Domain Driven Design • Tool to help decide for generic vs specific • But more about building something yourself or not • Subdomains (from perspective of custom software development): • Core domain • Supporting subdomain • Generic subdomain Strategic design Background source: GR Stocks on Unsplash
- 28. • Organisations 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
- 29. Conway’s law in action Background source: DALL·E
- 30. • Going generic may save time in the long run, but at which price? • 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 & planning overhead) The cost of a generic solution Background source: DALL·E
- 31. What if you get it wrong? Photo: Dave Lehl
- 32. • What are the costs of abstractions? Abstractions Background source: Héctor J. Rivas on Unsplash
- 33. • There are no zero cost abstractions • 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 standardisation! Generic vs specific in different scopes Background source: Fernando Gomez on Unsplash
- 39. Why specific is often faster
- 40. Code golf
- 41. 41
- 42. Advent of code
- 50. 50
- 51. 51
- 52. Generic solutions on organisation level
- 53. • 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 organisation Source: https://medium.com/@jeffwhelpley/the-problem-with-shared-code-124a20fc3d3b
- 54. • Challenges: • Refactoring • Versioning • Reviewing • Builds and codebase size Sharing code within an organisation Source: https://medium.com/@jeffwhelpley/the-problem-with-shared-code-124a20fc3d3b
- 55. • 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
- 56. • 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
- 57. Summary
- 58. • Consider: • YAGNI / Rule of three / 5 W’s • Cost of generic • Scope / level • Conway’s law • Organisation impact Generic or specific?
- 59. Generic or specific? It depends.
- 60. 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
- 61. Write. simple. code. Source: https://images.unsplash.com/photo-1515611926865-4fcb1c2ce28d?ixlib=rb-4.0.3&dl=kelly-sikkema-kxtB2TFBF2g-unsplash.jpg&q=80&fm=jpg&crop=entropy&cs=tinysrgb
- 64. Thanks for your time. Please rate this session by scanning the QR code! All pictures belong to their respective authors @bjschrijver.dev