Solving Problems & Saving Time through Software and Crushing Entropy
Powered by Cecil & Hyde.
A good friend and I were chatting about his job. He was talking about how they were putting in place a number of rules for all the people doing jobs like his. My natural instinct was that this must make it harder to do his job. That people are creating bureaucracy. He went into greater detail, but I really didn't know his industry to know heads from tails. He said that this was a good thing. He compared it to the design rules for cartoons. And it got me thinking.
Each cartoon has their own style. It's necessary to establish the brand and for differentiation. Rules communicate to viewers what to expect. And when you break the rules—its for effect. Though there are some rules that you don't break.
In addition to some of the simpler and strict rules like those above. There are guidelines to follow in order create the desired effect. I think about rules like these as if they were a director. The director knows where he wants to put the camera and why. Individual cartoonists may not know how or why to "move the camera."
These artifacts are written down guidelines to make sure everyone is on the same page about how we work together to achieve a cohesive look and story between dozens of different individuals. Everyone has their preferences and opinions. At the end of the day we do all need to work together towards a single destination.
My good friend then asked me:
What are the rules for your company?
I honestly had nothing that I could reasonably point to as an answer for him. As I look around the industry at-large I see "Thought Leaders". Many of them are very vague. The rules we saw for cartoons above are very specific. I really don't think I've ever seen something so specific before. On some level "if the compiler accepts it, it works!" is the bar, even if that bar is incredibly low.
We have to do better. On my very last project I started to do just that. I used ADRs to explain why I was refactoring code to fully utilized class-based views in django-rest-framework. I explained why I was moving code out of views and into serializers. I explained which methods you ought to be overriding to achieve your outcome. And which methods should not be overridden. I even had an example of when I had to break that rule. I wrote a knowledge base entry in our wiki and shared it with the wider dev team.
I received amazing positive feedback on what I was writing up from several people. This is definitely a practice I am going to repeat in the future.