Mere uniformity does not make for consistency

We often play the consistency card in the support of an argument.

I want this UI (form) to be laid out this way for the sake of consistency.

or

Let's be consistent and use the corporate presentation template.

or

I can't make an exception for you in case of this policy. We'll have to be consistent.

Used as above, consistency is an inappropriate substitute for uniformity. To check, ask "consistency with what?"

I want this UI (form) to be laid out this way for the sake of consistency.
    Consistency with what?
Consistency with the rest of the UI.
    You mean uniformity with the rest of the UI?
Isn't it the same thing?
    Well, laying it out this other way is consistent with the aim of keeping
    the user from making an incorrect assumption about the feature.

Let us all be consistent and use the corporate presentation template.
    Consistent with what?
With corporate guidelines of course.
    Guidelines don't demand uniformity. We could use our own templates as long as they are consistent with the image we want to portray as a company.
   
I can't make an exception for you in case of this policy. We'll have to be consistent.
    Consistent with what?
Consistent with the application of this policy.
    You mean you want to uniformly enforce the letter of the policy on everyone?
Well we certainly don't want to encourage exceptions.
    It seems you have already concluded that my case is an exception and one not worth granting.

Consistency is a higher order goal than mere uniformity. It requires some deliberation to decide if a certain course of action is consistent with broader objectives. On the other hand, uniformity is easily achieved by mechanical application of a rule book. This is what call center agents are trained to do. We know what the resulting user experience feels like. As Emerson said,

"A foolish consistency is the hobgoblin of little minds".

Why then, do we fall for this? Often, it is just laziness to listen and think. Sometimes (as in the case of call centers), it is side-effect of organisation design. Decision makers and policy makers sit on top of corporate hierarchies. They don't devolve discretionary powers to subordinates. The subordinates learn to function uniformly, without regard to context. They unconsciously cultivate a habit of using better sounding words like consistency to defend their actions. The makings of a classic bureaucracy!

Why continuous delivery needs devops, and why devops needs infrastructure-as-code

Update 02-Apr-13
Just came across this detailed relevant talk by Reinertsen - the author I reference for silo reduction and batch size reduction.


http://www.infoq.com/presentations/lean-product-dev
===============================================

Update 26-Oct-12

Slides, with notes
=========================

I'll present on this topic on 25th October 2012 as part of a ThoughtWorks Studios webinar series on continuous delivery. Please register from the webinar page.

Abstract
Continuous delivery and devops have gone mainstream, at least in terms of mindshare. As a result, a lot of vendors have jumped onto the bandwagon. Most products that have anything to do with deployment now try to associate themselves with devops and continuous delivery. In this webinar, Sriram will try to clear the air in a product independent manner. He will also cover common devops anti-patterns and explain the idea of infrastructure as code.

The economics of aesthetics

Many will argue that it is just plain wrong to subject aesthetics to cost and benefit, at least until a certain threshold. Someone said, “An economist is someone who knows the price of everything and the value of nothing.”

But this is the reality of business. A product or service can be made just useful or it can be made useful and beautiful. As consumers, we frequently choose from varying degrees of form and function. However, things get more interesting in a B2B situation.

Clients agree to foot the bill for aesthetics to the extent it promises to help their topline. Funds are made available for aesthetics on a public facing website. The belt is tightened for an internal facing application. Vendors use the same logic. They spend money to make sure that their presentations are not only substantial but also aesthetic enough to impress clients.

What about the people who write code? They also have a sense of aesthetics. Their bosses don’t grudge them the inexpensive effects – standard tools that can ensure uniform indentation, nice fonts and syntax highlighting. But higher order aesthetics are a different matter altogether.

I mean lucid, performant code, fluent interfaces, pithy names, succinct tests and coherent classes residing in cohesive modules loosely coupled with their neighbours.

“Don’t just call these aesthetics”, I hear the indignant coders say.

“They confer vitality, suppleness, and longevity to the codebase.”

There is truth and perhaps some irony to this claim. Unfortunately, even the truth is appreciated largely only by the coding intelligentsia. As a result, efforts to secure these higher order aesthetics go unchallenged only as long as the development team stays on track for budget and schedule. As Stewart Brand said, form follows funding.

But estimates being estimates and competitive bids being competitive bids, there is many a slip between the cup and the lip. Screws get tightened,

“Enough gold plating already.”

Some will contend that effective visualization of internal software quality will bring about the necessary loosening of purse strings. Well, only occasionally. For one, a common (and sometimes legitimate) reaction is,

“Why did you incur technical debt in the first place? That’s not why I hired expensive consultants like you.”

But first, there is the question what makes for effective visualization. Should we show a tangled ball of wool versus a neatly wound ball in order to contrast the current cyclomatic complexity with desired state? Should we progressively untangle the ball in progress reports? Is it not enough to state in text that the industry standard is about 20 per 100 hundred lines of code and that we are currently at 45?

Should we depict a slummy urban sprawl for a monolithic codebase and gradually introduce suburbia with zoning as we modularize? Is it not enough to show a dependency structure matrix?

How accessible does a visual need to be before a non-technical/post-technical decision maker gets it? One kind of visual targets the recipient’s analytical faculty. Another kind targets their aesthetic faculty. Aesthetics are in vogue among consumer devices. I suspect this has spilt over to the kind of visuals favoured by IT decision makers.

They very people who scrutinize spend on aesthetics through the lens of the topline lean towards aesthetics when they ask their sub-ordinates and vendors to send them reports and presentations.