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

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
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
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