Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Abstracting Too Early

Matt Stauffer
September 14, 2022

Abstracting Too Early

Our best intentions for planning for the future all too commonly lead to reaching for abstractions and other complicated tools and processes long before we need them.

This talks shares ideas on how to consider abstractions in general, and then dives into some very common premature abstractions, the costs and benefits of each, when they make sense and when they don't, and how to approach them when you do choose to use them.

Links in a clickable form: https://gist.github.com/mattstauffer/f27164819b1fb948640bde2e273db01c

Matt Stauffer

September 14, 2022
Tweet

More Decks by Matt Stauffer

Other Decks in Technology

Transcript

  1. Matt Stauffer - Laracon 2022 Abstracting 
 too early

  2. Matt Stauffer - Laracon 2022 Abstracting/complicating 
 too early

  3. Part 1 : Story Time

  4. Part 1 : Story Time

  5. Part 1 : Story Time

  6. Part 1 : Story Time

  7. Abstracting too early - Laracon 2022 What does this story

    mean?
  8. In this talk, you are the young warrior… 
 


  9. In this talk, you are the young warrior… 
 


    and microservices are the King’s Armor.
  10. In this talk, you are the young warrior… 
 


    and Kubernetes is the King’s Armor.
  11. In this talk, you are the young warrior… 
 


    and Docker is the King’s Armor.
  12. In this talk, you are the young warrior… 
 


    and repositories are the King’s Armor.
  13. In this talk, you are the young warrior… 
 


    and event sourcing is the King’s Armor.
  14. In this talk, you are the young warrior… 
 


    and separate repos is the King’s Armor.
  15. TL;DR : YAGNI

  16. None
  17. Part 2 : A Healthy Attitude Toward Abstraction

  18. YAGNI

  19. Abstracting too early - Laracon 2022 YAGNI : The basics

    • YAGNI means "You Aren't Gonna Need It" • ( Or, as I prefer it, "Ya Ain't Gonna Need It!") • We suck at predicting the future • Counter to: Control against bad outcomes with abstractions & planning PART 2 : YAGNI
  20. The Origins of YAGNI

  21. The Origins of YAGNI

  22. Abstracting too early - Laracon 2022 The Agile Manifesto “Welcome

    changing requirements, even late in development.”
  23. Abstracting too early - Laracon 2022 Sara Bine, on the

    Twenty Percent Time Podcast "When faced with multiple paths choose the simplest.”
  24. Abstracting too early - Laracon 2022 Sara Bine, on the

    Twenty Percent Time Podcast "Leave your options open.”
  25. Abstracting too early - Laracon 2022 Sara Bine, on the

    Twenty Percent Time Podcast "It is very, very easy to turn simple code into complex code later, but it's extremely hard if not impossible to turn complex code into simple code."
  26. Abstracting too early - Laracon 2022 “Long term plans are

    pernicious” PART 2 : YAGNI
  27. Abstracting too early - Laracon 2022 “Long term plans are

    pernicious” • "Yearly software development plans are my favourite genre of fiction" • Two types of long-term code plans: • Imaginative assumes nothing will go wrong • Naive assumes you can solve for unexpected events by adding buffer • The one valid alternative to a long-term plan: make your plan shorter PART 2 : YAGNI
  28. Duplication is far cheaper than the wrong abstraction

  29. None
  30. Abstracting too early - Laracon 2022 Duplication > wrong abstraction

    • Sandi Metz slide and then subsequent blog post • An existing abstraction has momentum • New devs will continue, and add on to, the abstraction rather than fix or remove it • The wrong abstraction will severely increase ongoing cost of change PART 2 : DUPLICATION IS FAR CHEAPER THAN THE WRONG ABSTRACTION
  31. Abstracting too early - Laracon 2022 💩 on DRY &

    SoC • SoC : overrated (what does it mean??? ) • DRY : overrated and abused PART 2 : DUPLICATION IS FAR CHEAPER THAN THE WRONG ABSTRACTION
  32. Abstracting too early - Laracon 2022 💩 on DRY &

    SoC PART 2 : DUPLICATION IS FAR CHEAPER THAN THE WRONG ABSTRACTION
  33. Abstractions aren’t free

  34. Abstracting too early - Laracon 2022 Abstractions aren’t free •

    Every abstraction introduces some cost • coordinating deploys • finding the code • getting it right (if it's new for you) • ongoing maintenance cost/required expertise • constraints for all future development • You'll never reach scale if you waste your time and energy making it "scaleable" ABSTRACTIONS AREN’T FREE
  35. Work to your team

  36. Abstracting too early - Laracon 2022 Work to your team

    WORK TO YOUR TEAM
  37. Abstracting too early - Laracon 2022 You are not Amazon.

    Source: Reality WORK TO YOUR TEAM
  38. Abstracting too early - Laracon 2022 You are not 


    Netflix. Source: Reality WORK TO YOUR TEAM
  39. Abstracting too early - Laracon 2022 Work to your team

    • Not every tool works for every team • How many people do you have? • How many know that new technology? WORK TO YOUR TEAM
  40. Prepare for extraction

  41. Abstracting too early - Laracon 2022 Extraction misconception •Misconception: extraction

    fixes structural issues. •Reality: extraction cements existing problems PREPARE FOR ABSTRACTION
  42. Abstracting too early - Laracon 2022 Refactor first • Most

    abstractions and extractions require re-architecture/re-factoring, modularization, etc... so just do that first! • Never extract without first refactoring PREPARE FOR ABSTRACTION
  43. Part 3 : Common Premature Abstractions

  44. Abstracting too early - Laracon 2022 Sections for each example

    • What is it • Why do people want it • The dangers • When it makes the most sense • How to approach it wisely
  45. Repository Pattern

  46. Abstracting too early - Laracon 2022 What is it •

    Create a “repository” class that your app interacts with instead of interacting directly with the database ORM • Instead of Person : : all() you call PersonRepository :: getAllPeople() PART 3 : REPOSITORY PATTERN
  47. Abstracting too early - Laracon 2022 Why people want it

    • Loose coupling • Maybe we'll change database drivers one day • Encapsulate complex model logic outside the model PART 3 : REPOSITORY PATTERN
  48. Abstracting too early - Laracon 2022 The dangers • Extra

    class for every model • Extra method for every type of call • Doesn't actually extract because you're still relying on collections of data returned and methods usually match the calls made by the underlying DB • Method names like FindAuthorByIdScopedToTenant... and worse PART 3 : REPOSITORY PATTERN
  49. Abstracting too early - Laracon 2022 When it makes the

    most sense • Lots of complex database logic and a preference for clean models PART 3 : REPOSITORY PATTERN
  50. Abstracting too early - Laracon 2022 How to approach it

    wisely • Don’t use it unless you need it • Don't do it because it's "better", or because "one day we may change DB drivers", do it because it's going to actually solve a real need PART 3 : REPOSITORY PATTERN
  51. Microservices

  52. Abstracting too early - Laracon 2022 What is it •

    Split one or more of the pieces of your application off into smaller applications, in separate codebases, hosted separately, sometimes in other languages PART 3 : MICROSERVICES
  53. Abstracting too early - Laracon 2022 Why people want it

    • Scaling–especially scaling different parts of the app at different speeds • Different languages/frameworks for each part of your app • Modularity • Fault isolation PART 3 : MICROSERVICES
  54. Abstracting too early - Laracon 2022 "grug wonder why big

    brain take hardest problem, factoring system correctly, and introduce network call too" Grug, grugbrain.dev PART 3 : MICROSERVICES
  55. Abstracting too early - Laracon 2022 The dangers • New

    validation issues, authentication issues, firewall & HTTP issues, etc. • More codebases, more complicated deploys • One dev introduces a Phoenix/Rust/Golang dependency and now you have to employ a Rust programmer forever • Have to build entire messaging systems ( Kafka etc.) PART 3 : MICROSERVICES
  56. Abstracting too early - Laracon 2022 When it makes the

    most sense • When one piece of your app truly, not hypothetically, has different needs for scale, etc., so badly that the costs of microservices are outweighed • If one piece of your app could runaway with memory usage etc. and potentially take down the rest of the app (e.g. encoding video) • If there's a demonstrated need for concurrency/speed that your primary language can't support that another technology could PART 3 : MICROSERVICES
  57. Abstracting too early - Laracon 2022 How to approach it

    wisely • Prepare for extraction ("modularize your monolith") • Get your ops set up so you can actually spin servers up and down easily, and load balance • Don't extract until you need to • Keep it in the same language if possible PART 3 : MICROSERVICES
  58. Complicated hosting (e.g. Kubernetes)

  59. Abstracting too early - Laracon 2022 What is it •

    Any hosting setup that requires or suggests dedicated ops people • Kubernetes is one example; it’s an infrustracture-as-code tool for “automating deployment, scaling, and management of containerized applications” PART 3 : COMPLICATED HOSTING ( E.G. KUBERNETES )
  60. Abstracting too early - Laracon 2022 Why people want it

    • The perception that simpler hosting won't scale (shiny object syndrome) • Automatic management of load balancing, resource scaling, health management, etc. • IaC : want to make server management documented, repeatable, committed to source control PART 3 : COMPLICATED HOSTING ( E.G. KUBERNETES )
  61. Abstracting too early - Laracon 2022 The dangers • It's

    So. Freaking. Complex. • Complicated to set up • Complicated to manage • Requires an ops person, or provides your one Kubernetes nerd with job security PART 3 : COMPLICATED HOSTING ( E.G. KUBERNETES )
  62. Abstracting too early - Laracon 2022 When it makes the

    most sense • When the existing automated hosting tools (e.g. Forge, Envoyer, Vapor) no longer meet your immediate or short-term needs for scale PART 3 : COMPLICATED HOSTING ( E.G. KUBERNETES )
  63. Abstracting too early - Laracon 2022 How to approach it

    wisely • Don’t move to it unless you need it • Ensure you have a dedicated person to handle dev-ops • Wait to move until your existing hosting tools have measurable difficulty at your current or short-term predicted scale PART 3 : COMPLICATED HOSTING ( E.G. KUBERNETES )
  64. Complex custom local setups (e.g. Docker)

  65. Abstracting too early - Laracon 2022 What is it •

    Any local dev setup that involves a custom-built solution like custom Dockerfiles, a custom Vagrant file, etc. PART 3 : COMPLEX CUSTOM LOCAL SETUPS
  66. Abstracting too early - Laracon 2022 Why people want it

    • Dev environment perfectly mirrors prod • It's shiny✨ PART 3 : COMPLEX CUSTOM LOCAL SETUPS
  67. Abstracting too early - Laracon 2022 "I watched 62% of

    a video course about Docker" 
 
 is not the same as 
 
 "I can build a local Docker build that won't screw everyone on the team over as I have to fix it 100 times” PART 3 : COMPLEX CUSTOM LOCAL SETUPS
  68. Abstracting too early - Laracon 2022 The dangers • Onboarding

    more costly; setting up local setup the first time always 10x more expensive than your shiny-object-syndrome dev expects • Modifying local setups now becomes more costly • You need to have "Docker person" around; "The guy who set this up doesn't work here anymore or isn't in today 🤷” PART 3 : COMPLEX CUSTOM LOCAL SETUPS
  69. Abstracting too early - Laracon 2022 When it makes the

    most sense • If you've started with the simplest options ( Sail, Valet, Homestead, etc.) and felt a real pain point PART 3 : COMPLEX CUSTOM LOCAL SETUPS
  70. Abstracting too early - Laracon 2022 How to approach it

    wisely • Don't do it unless you need it • Don't do it for an actual team if you've never done it for fun before • Consider bringing in a professional PART 3 : COMPLEX CUSTOM LOCAL SETUPS
  71. Extracting components/ classes to libraries

  72. Abstracting too early - Laracon 2022 What is it •

    Taking pieces of your application and extracting them to frontend and/or backend components • Extracted components are in other codebases and often loaded via package managers PART 3 : EXTRACTING TO LIBRARIES
  73. Abstracting too early - Laracon 2022 Why people want it

    • Code reuse across different projects PART 3 : EXTRACTING TO LIBRARIES
  74. Abstracting too early - Laracon 2022 The dangers • Coordinating

    deploys across multiple projects • Making breaking changes to support one project now forces work on other projects • SemVer to modify your authentication tools?! Painful PART 3 : EXTRACTING TO LIBRARIES
  75. Abstracting too early - Laracon 2022 When it makes the

    most sense • Multiple projects using utilities/helpers or other code that would make sense as a package PART 3 : EXTRACTING TO LIBRARIES
  76. Abstracting too early - Laracon 2022 How to approach it

    wisely • Don't extract until you need it • Don't extract unless it would make sense as a Composer or NPM package • Extract as little as possible, and extract tools with minimal public surface area PART 3 : EXTRACTING TO LIBRARIES
  77. Event Sourcing

  78. Abstracting too early - Laracon 2022 What is it •

    A DDD-related tool where, instead of having resources in your database that can be modified, you have events in your event store and to find the current status of your resources, you can play the events through over time PART 3 : EVENT SOURCING
  79. Abstracting too early - Laracon 2022 Why people want it

    • Just re-run all your projections and magic tada • Full history of EVERYTHING THAT EVER HAPPENED • “Event storming” just sounds fun 😆 PART 3 : EVENT SOURCING
  80. Abstracting too early - Laracon 2022 The dangers • Not

    the right fit for the vast majority of applications • Even for appropriate apps, only some of the app should be event sourced • Communicating between event sourced & stateful sections of apps can be tricky PART 3 : EVENT SOURCING
  81. Abstracting too early - Laracon 2022 When it makes the

    most sense • Projects/applications based on events (banking, shipping, manufacturing, insurance, etc.) • Other projects where you NEED to be able to evaluate and prove every action PART 3 : EVENT SOURCING
  82. Abstracting too early - Laracon 2022 How to approach it

    wisely • Don’t use it unless you need it • Only apply it to the smallest part of your app possible • Research & plan how to handle internal communication between event sourced & stateful (non event sourced) code PART 3 : EVENT SOURCING
  83. Abstracting too early - Laracon 2022 • We can't predict

    the future • Abstractions aren't free • Write simple code that's easy to change or delete • Many abstractions cement your problems; fix your existing code, don't reach for shiny objects In summary
  84. Thank you!

  85. Abstracting too early - Laracon 2022 Links • https://specbranch.com/posts/one-big-server/ •

    https://itnext.io/you-dont-need-microservices-2ad8508b9e27 • https://www.youtube.com/watch?v=uQUxJObxTUs • https://www.youtube.com/watch?v=y8OnoxKotPQ • https://tighten.com/blog/tpt-yagni/ • https://segment.com/blog/goodbye-microservices/ • https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction • https://lucasfcosta.com/2022/07/15/long-term-plans-dont-work.html • https://martinfowler.com/bliki/MicroservicePrerequisites.html • https://grugbrain.dev/ • https://martinfowler.com/bliki/MicroservicePrerequisites.html • https://stitcher.io/blog/combining-event-sourcing-and-stateful-systems