A foolish consistency...

 "A foolish consistency is the hobgoblin of little minds" -- R.W. Emerson

I used to hate that quote. I hated it because people would misquote Emerson all the time by leaving off the 'A Foolish' at the beginning. Consistency has its purposes.

I previously wrote on code being consistent in its structure in order to reduce cognitive load. That same thinking can be applied elsewhere.

Standards

Recently I've been working with my team to develop standards and processes for our organization. We're focused at the moment on identifying known standards and capturing those in one place. But in some cases, the known standards aren't written yet. This is a big problem in the sense that there are dozens of standards and keeping them consistent and well-organized is proving difficult. 

We are doing this because we are trying to create consistency across our organization. The consistency that we believe will enable us to easily automate processes. Our mission is to reduce the friction of putting code into production. 

My Personal Dichotomy

Among the dozens of identified standards we have identified are choices about tools, technology stacks, and language standards. I personally am working on the standard for Python development. 

Anyone who's worked with me before should know that I'm personally indifferent to style guides in programming. That is, I don't care what the standard is, I care that the standard exists. You'll also know I'm not a big fan of PEP-8 or the defaults in pylint. So maybe it's ironic that my standard on Python says 'start with PEP-8 and use pylint'.

Consistency Can Increase Value

I won't drag you through my philosophical arguments against the defaults. I want to talk about value delivery and speed and how any standard enables that. 

Having a programming standard that is enforceable (and hopefully auto-fixable) gives me an advantage when I code. Taking 30 minutes to setup pylint and my IDE for auto-formatting lets me stop thinking about formatting and style. Those things become one less thing I need to do before creating a pull request. Minimally I don't have a colleague checking the rules for me. Ideally, my IDE corrects the issues as I create them. That allows me to work on problems that really matter.

Not Foolish, Pragmatic

The consistency of the standard isn't foolish. We're making this choice to remove a whole realm of discussion from the production of software. We are working to reduce friction and speed up development so we can deliver more value more often. Part of that is the standard itself and how it impacts our reasoning about code and part of that is leveraging or enabling automation. Remember, it's a choice to do things consistently, the standard is mostly an opinion on correctness. Don't blindly follow a standard, understand why you have it and what you get for having it. My advice is 'steal a standard' and tweak it, but don't 'not have a standard' and find a way to automatically enact and enforce the standard.