System Design (3 blogmarks)

The last two products I worked on benefited greatly from adding a separate concept of entitlements so that access to features could be mediated with more flexibility than a billing_status == 'active' check.

So herein lies the problem: if you ever want to make any change to your company’s offering, or if you find yourself expanding to new territories, you really should have a separate mechanism to handle entitlements.

In blunt terms:

1. If you will change what features are included in a plan, you should have a separate entitlement system.
2. If you think you won’t want to force customers onto new plans, you should have a separate entitlement system.
3. If some features are optional add-ons, you should have a separate entitlement system.
4. If you ever hope to expand to new countries and markets, you should have a separate entitlement system.
5. If you want to let customers experience features separately from their billing status, you guessed it… You should have a separate entitlement system!

There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more intelligent type of reformer will do well to answer: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.”

I’ve often seen this concept used to talk about rashly throwing things away in a software development context. Anything from a misunderstood conditional check to an entire piece of infrastructure. “This doesn’t make sense, let’s refactor it.” Make it make sense first!

This is part of why I’m very cautious when it comes to refactoring legacy code. I’d much rather avoid the temptation of a few cathartic refactors while fixing some bug and avoid the pain of later finding out I broke a narrow use case.

It’s just as applicable to any setting/field where a (over-)confident person sees a policy, practice, or even something physical like a fence and is ready to get rid of it without understanding why it is there.

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

Or put another way as I’ve also seen this concept described:

Organizations design systems that mirror their own communication structures.

Fowler gives a concise example of what this can look like.

if a single team writes a compiler, it will be a one-pass compiler, but if the team is divided into two, then it will be a two-pass compiler.

It’s not that there is a wrong or right way for an organization to communicate, but rather that an organization should ensure there isn’t dissonance between communication structures and system design.

We often see how inattention to the law can twist system architectures. If an architecture is designed at odds with the development organization's structure, then tensions appear in the software structure. Module interactions that were designed to be straightforward become complicated, because the teams responsible for them don't work together well.

I was reminded of Conway’s Law because it was mentioned in Pierre’s new landing page.