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.