Common Libraries – How to avoid Premature Optimisation

Common Libraries can be a great way to get a new project started and productive quickly, particularly for teams, or companies with a broad set of services on their books.

They can also be the source of a great amount of friction when done too early.

Premature Optimisation is the Root of all Evil – Donald Knuth

Before diving in and creating a new “Common” project ask yourself a few questions:

  1. Do you understand the problem well enough to define an API appropriate for use across multiple projects?
    Without anecdotally requiring a solution to a problem across multiple projects the answer to this is no.  This is your starting point. Understand your requirements.
  2. Do you understand the solution to your problem well enough to create an implementation that’s genuinely fit for purpose, won’t change every time a new project comes along, and is appropriate to cover the use case(s)?
    Implement your solution at least twice alongside the problem.  First time through by nature isn’t shared, second time through, tackle it in isolation to the first.  Apply lessons learnt and refactor accordingly.  Don’t create common projects with only one consumer,  YAGNI (You aren’t gonna need it).
  3. Code should follow the DRY (Don’t Repeat Yourself) Principle where possible, but do you understand whether the Repetition is truly a Repetition, or is it coincidental?
    Microservice architectures aim to create isolated deployable units, be mindful of binding solutions together at points that shouldn’t be there through shared code artefacts.  Understand your service architecture and adhere to their interface.
  4. Do you have a clear way to deploy change to your common code?  Should your update be implicit or explicit?
    Internal Nuget Feeds are a great way to share code, less great ways could be SVN Externals or sharing DLL’s, wouldn’t advocate this but it does happen.  Understand what will work best for your environment.  Should your changes be rolled out across the board, or should they be opted in for through a new version of a package?
  5. Do you understand the impact of change on consumers?  Will “just” adding an extra enum value cause all of your other consumers to come grinding to a halt?  What will happen if you add an external dependency?
    A healthy set of unit tests should go some way to covering this.  Always be mindful of supporting the lowest common denominator and plan an integration strategy accordingly.  Nuget is great at managing version mismatches across dependencies, and takes away a lot of the pain, this doesn’t mean it shouldn’t be a consideration.

Common Libraries, when done well, can enhance efficiency.  They can also easily get out of hand.  All code is Legacy Code once it’s been committed, it’s crucial that shared components be maintained and understood by the team, both in their implementation and integration to the services they’re used in.

Have you ever found yourself slowed down by attempting to share code?  What issues have you experienced?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s