Single Responsibility and Conway’s Law
It’s easier to think about a problem if you can isolate the important information. Otherwise you begin to suffer from the curse of dimensionality. Yes, that’s a more machine learning way of saying:
do one thing and do it well — Unix Philosophy, Ken Thompson
It’s also important to organize our communication structures (squads) how we want our system to be designed.
organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations — Melvin Conway
I am thinking a lot about these two very poignant observations, and how they work together. I am responsible, along with my team, for building platform level tools to support internal tools user interfaces. Currently, we communicate with other engineers by showing them what we’ve built. What I really think we should be doing is publishing an API that gives them access to a user interface, as a service.
We need to change the way we communicate first. Our current pattern is showing engineers an application we built for generating static sites using React/Relay/GraphQL and Page Factories.
I know my squad needs to handle one thing, and do it well. I know that how we communicate as a squad will be copied in our system designs. So, I think we need to think about the system we want, and change the way we communicate to match.
The System We Want
We want a system where the data we collect is complete, valid, and accessible. I think that means we need a system where our users can enter in information to a user interface that is complete, valid, and accessible.
Complete User Interface
This means that every kind of information we collect has it’s own user interface. We want user interfaces that are reusable (DRY).
Valid User Interface
This means that every user interface displays and collects the correct type and format of data we want. We want a canonical set of user interfaces for each type of information we need.
Accessible User Interface
This means that every user interface is well designed, easy to read, easy to use, and relays all the appropriate signals about the information.
The system we want allows us to accomplish the above objectives in a DRY way. We want to avoid having to build twice, the same UI for accessing information.
The Single Responsibility
Our aim is to build a service that can generate user interfaces to collect customer information (like pay-stubs, or a driver’s license), while providing complete, validation, and accessible data. Our system doesn’t need to know where the information we collect will be saved. This service only needs to do one thing: collect information from a user.
Another service could make a request to this UI-service to provision a page to collect certain information. The request would include a URL to send (POST) any user activity. Our service could present this user interface to any user, to collect this certain information. Whenever a customer modifies the information in the user interface, our service will POST to the URL the updates with the user information as the payload.