I ain’t got no standards
In 1789, Thomas Jefferson fired up a letter to James Madison. It was basically the equivalent of a Twitter rant of the time, only that during those times rants had to be coherent, researched, and had to read like op-ed pieces from the New York Times.
So spoke Tommy J:
“…it may be proved that no society can make a perpetual constitution, or even a perpetual law. The earth belongs always to the living generation. They may manage it then, and what proceeds from it, as they please, during their usufruct. They are masters too of their own persons, and consequently may govern them as they please. But persons and property make the sum of the objects of government. The constitution and the laws of their predecessors extinguished then in their natural course with those who gave them being. This could preserve that being till it ceased to be itself, and no longer. Every constitution then, and every law, naturally expires at the end of 19 years. If it be enforced longer, it is an act of force, and not of right. — It may be said that the succeeding generation exercising in fact the power of repeal, this leaves them as free as if the constitution or law has been expressly limited to 19 years only.”
Deep. Deeper than Jerry Springer’s final thought. Imagine that, the idea that an entire constitution of a country is up for questioning after 19 years because times change faster than laws. The idea that policy can never be ahead of practice, and that there’s a pretty good chance that newer citizens of the earth will be in a better position to write the laws that govern them, than people who can’t experience or be impacted by current events.
I subscribe to this line of thinking, and before you think I’m suggesting lighting fire to the National Treasure trove of documents, let me be clear that I’m not. I’m just saying it’s optional, and that better options possibly exist. Scratch that, possibly is a weasel word. Better options definitely exist, and people deserve a right to pursue them without having to worry about dogma or violating some arcane law that nobody really understands.
The constitution that Thomas Jefferson‘s poking at can be mapped to something very similar in the technology world: standards.
It’s a word that pops up often enough and never fails to make me cringe. It’s that word that encourages inaction, promotes stagnation, and rewards compliance at the expense of innovation.
The problem with standards is that they’re rarely reviewed with a view to be updated, and once set, they become set in stone and used by architects to thwart enthusiastic engineers who would like to move away from the misery of Ant. There isn’t a developer around that hasn’t tried to introduce an improvement, whether it be a library, pattern, tool, framework, or even a process, only to be told that it doesn’t comply with ‘standards’. It’s disheartening, demotivating, and promotes developer decay.
I’m not suggesting that we become aggressive and start updating our toolkits and technologies at the sight of something new and shiny. That would be just as irresponsible as having age-old rules that no longer apply, perhaps even more so. What I am saying is that if there aren’t honest, open-ended, periodic reviews of what technologies, processes, and approaches you’re dictating your IT organization use, then you’re already dead. And by ‘periodic review’, I don’t mean yearly because that’s about as good as never. It should be a hunt for continuous improvement, not a formality.
In my view, standards can never be imposed top-down. Architects, unless they actually code, are in no position to dictate tooling, frameworks, and the like, because they don’t have to suffer the consequences of the decisions. And as a wise man once said, try not to take advice from someone who doesn’t have to live with the consequences.
Standards have to be created bottom-up, and the challenge most organizations face is that they don’t have the culture, process, or know-how of how to cultivate ideas at the trench-level, and bubble them up so they become the new approach. The hierarchical, silo’d nature of organizations essentially kills off any hope of horizontal collaboration and fostering of ideas, and if you’re telling me a monthly developer meeting is your idea of ‘knowledge sharing”, well, shut your company down and open up a lemonade stand because in the long-term it’ll be more profitable.
The popular, trendy, and mildly smug Spotify approach of organization is on the right track because it gets rid of hierarchies, promotes inter-team communication, and at the very least, creates a structure where ideas can be brought to the fore and put to vote for adoption. You’re not left waiting for the lumbering architect to peel away from his UML diagrams and start testing out Java 5 so you can finally right a for loop without having to track indices.
Many implementations of the Spotify approach have serious issues because they’ve been adopted verbatim and failed. As with anything, one has to apply the thinking to your specific context. However, that’s a problem with the implementation and not the idea. Most organizations can simply benefit from the concept of a Chapter, but only if its actually empowered to make lasting change. And that’s where the problem lies. Nobody has an issue if people in horizontals meet to talk things over, but as soon as they recommend a change, the people a level or two higher shiver up and hide because there is absolutely no reason to risk something when things are ‘fine’.
The incentive to make change is low since the reward systems are misplaced, and the risk of action is too high. Why would an architect risk taking action on a recommendation to switch from Ant to Maven, or from Maven to Gradle, when things are working ‘just fine’? Why would he risk failure when ‘success’ is guaranteed by doing nothing?
At the intersection of fear of change, misplaced reward systems, and the need to protect yourself through layers of people, lay standards. In most cases, they give the illusion of predictability and safety, when in reality they’re like underwear: needs to be changed frequently lest you risk infection.
This post isn’t going to provide you answers on how to develop standards, and more importantly, keep them relevant. However, I do believe that what we really mean when we say ‘standards’ is predictability and repeatability, both of which are good things. The missing vector in this conversation is continuous improvement. That culture and commitment is what most organizations lack when maintaining standards, and it’s where agile thinking can help. Whether it be retrospectives, unconferences, retreats, or even a lunch and learn, how willingly we view the output of these gatherings and pipe them through a (hopefully simple) process where they can be transformed into a better way of doing things is where the gap lies. The good news is that this gap isn’t difficult to fill, the bad news is that there’s a popular perception that there’s no need to fill it.
You can block me on Twitter at @CornerSniper. If you haven’t already, do so now.