Hobgoblins

Back in college there were a couple of people who liked to remind the world that 'Consistency is the hobgoblin of little minds'. They were forgetting an important word in that quote, foolish. The original quote says 'A foolish consistency is the hobgoblin of little minds' -- Emerson

I think Emerson was after a slightly different point, thinking about thinking and not elaborating on foolish v wise. However, there is something here that I find very interesting.

What we do

As developers we spend a lot of time trying to be consistent. We name things using patterns. We use Patterns in our code to make things similar. We define standards and enforce them. And we have static analysis tools to make sure we follow 'the rules'.  

What we fail at

What we seem to fail to do is reconsider the 'Why' behind our consistency. In my opinion, at least in this case, we can distinguish foolish from wise by making this evaluation. 

My Best Example

I grew up in a Dijkstra philosophy zone.  I will attribute some (or all) of my belief system to him, though he hasn't been my only influence. From this basis I used to believe that a function should only ever have one return point, period. As a result I spent a lot of time writing my code with single return points and spending a lot of time 'fixing' other peoples code to ensure that it had only one return point. I did this for the first 18 years of my career, to the point that I frequently ranted at other developers for failing to do this and extolling the virtues of the single return point. 

In roughly 2010 my team challenged my single return point thinking. In a fit of self examination I realized that while the single return point thinking makes sense in some cases, it isn't necessarily universally true. For example, in a three line function its not likely I'll loose track of the return points. Another example might be a matcher that checks 20-30 fields for equality; it could exit on the first violation just as easily as setting a local variable and exiting at the end. 

I still adhere to the single return point thinking for the most part as part of my personal discipline; not always, but usually. But I've given up the ranting. 

Consider this...

Almost everything we do should occasionally be reconsidered from the perspective of 'Why'. One great way of finding these things is to pair with a more junior developer and try to explain to them the 'Why' of every decision we make. Obviously it would be inefficient to discuss absolutely everything, but if we throw those discussions into our conversation we can discover things we do that aren't necessarily good, just 'the way we've always done it'. It can also help us discover false premisses or better yet, discover new and better ways to do things.