Generic or Specific? Making sensible software design decisions
Abstract
Specific solution:
- Tailor-made for use in a single place.
- Tailored to a specific problem or scenario.
- May not be easily adaptable to other situations.
Generic solution:
- 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.
- Generic solution = coupling!
Be aware of DRY: duplicate code doesn’t hurt until you need to change it. Sometimes, some code won’t ever change.
There are multiple levels for generic vs specific:
- code / class level
- manually written vs generated code
- library level
- data level (or data structure level)
- (micro)service level
- organization level
Some tools to help decide:
- 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
- When reusing code, copy it once, and only abstract the third time.
- It’s easier to make a good abstraction from duplicated code than to refactor the wrong abstraction.
- First case: just build it, don’t genericise at all. Solve the problem in front of you.
- Second case: duplicate the original, redesign and extract common behavior 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.
- Future needs and evolution.
The cost of abstraction:
- There are no zero cost abstractions.
- Onboarding new people.
- Readability.
- Writing bad abstractions.
- Maintain bad abstractions.
The speaker talked about a special architect archetype: the seagull architect. This one comes, eat the food of the developer, then leaves while shitting on them. Kinda fun anecdote.