Learn to Code: Finding Your Abstraction Sweet Spot by Johnny Austin
Many would argue there are only two hard problems in software: naming and cache invalidation. I’d argue there’s a third problem - abstractions. Whether you’re implementing an API for devs outside of your organization or creating a reusable library for devs on your team, creating the right level of abstraction is difficult. You have to balance flexibility with the ease-of-use. The correct choice is often a function of time constraints, compromise, and trial & error. I’ll talk about how to navigate these issues more efficiently.
Instead of KISS, go for Elegance - complexity expressed simply. Simplicity doesn’t scale.
What is an abstraction? The degree to which complexity is encapsulated.
- encapsulates a lot of complexity
- not necessarily a good thing
- encapsulates little complexity
- can be great
Abstractions - what can go wrong?
- breaking changes (reduces stability)
- tech debt (if you keep backwards compatibility)
- user confusion as things change
Where is the sweet spot?
- flexibility vs. ease of use
- how much customization to give your users vs. making it easier on a higher level
- do others need to use your stuff? What are they building?
- some platforms lend themselves better to abstraction
- api lifespan
- always think about your audience
Strong to weak abstraction is a spectrum and somtimes one or the other will make more sense. It will need to be determined at need, but these are the things that can help you determine how far to go.