Too Much Consistency

Can you actually be too consistent?  Is there such thing as abiding too closely to rules set forth?  Put another way, consistency is really about predictability — patterns that repeat themselves.  If the layout of my user profile page follows a two-column design, I should probably use two-column layouts on my blog entry pages.  And on my comment pages. You know what, it wouldn't make sense not to use two-column layout anywhere on the site, right?

Consistency is merely a principle, a convenient and useful one at that. You won't be forever banished from user interface design should you decide to mix things up a little.  If you feel forced to use a particular pattern just because it was used elsewhere, maybe you're pointed toward, what should we call this, flawed consistency?  Anyway, if it feels and looks flawed, and the driving force are the rules of predictability, change it.

Consistency Feels Good
Is it the act of doing something consistently that feels good, or it's side-effects?  Being predictable in how we work isn't easy — you often need to go out of your way to make sure you're using the right dependencies, using the right theme, following consistent naming conventions.  It can be exhausting, but in the end, you've made something that permeates.  Being consistent yields a feeling of producing a missing puzzle piece to help activate the larger whole.  Or maybe following the given rules set forth by the team makes us consistent out of fear.  The fear of standing out as the careless one, too lazy to play by the rules and make something that everyone understands.

I think consistency, and the good feeling we get from practising it, is something we can't exactly measure.  I think its part of the personality trait that drives us to build software in the first place.  Order out of chaos, and so on.

But let's not forget, we're seldom consistent with what we build right out of the gates.  If we were, it would take forever to investigate our mild curiosities that lead to production system components.  It takes time, we have to gradually evolve to become self-consistent — with our own code.  It takes even longer before the stuff we're inventing becomes a seamless shape, composed of a team's efforts.  So, stepping back to the pre-consistency stage of software development — where is the joy in hammering out lines that don't gel with one another?  The joy is in making it work.  We can be consistent to our heart's content, but it means nothing if it doesn't work.

Consistency Is Iterative
It's almost as though consistency is a side-effect of good engineering.  How often do you look at ugly code that works great?  Not very, I would imagine.  The goal with developing software, in early iterations, is to get something working.  The confidence boost necessary for continued momentum.  After which, we get an icky feeling — something just doesn't seem right about the code.  We've left some commented-out experiments in sections, some conventions weren't followed entirely, if at all.

This marks the beginning of an iteration whereby the consistent, clean-feeling code is established.  Funny isn't it — clean code usually translates to consistent code.

And then we're back to grit mode — doing battle, using what's in our toolbox to break down obstacles.  A system that doesn't oscillate between making things that work and aligning those things with sanctioned conventions is a system that fails to evolve.  We have two principles at work here, both of which favour our programming habits.  We have an urge to create, and an urge to cultivate.  We're also perfectionists, which tends to disrupt the happy development cycle.

Consistency Can Be Disruptive
Sure, beautiful code is ideal — sought after, even.  Just how much time should be spent pursuing this perfection?  If it's got to be perfect, the answer is a simple one — as much time as it takes.  Is there such thing as perfect software?  Of course not!  Getting caught up in making your software consistent in every sense of the word just isn't going to happen.  Consistency is a multi-dimensional problem with software systems.  You've got the code itself, which is difficult, and you've got everything else, facing the outside world. The user interface, the API, the operating system interfaces, and any other system that plays a role in the ultimate architecture of your software.

Compounding the challenge of achieving consistency in software development are the inescapable trade-offs one has to make.  Time consuming as this re-factoring and general cleanup work is, there is always more to do.  These tasks are investigative by nature, yielding discoveries of inconsistency that beg to be resolved.

But should they be resolved?  Do you have time to upset the cycle of creation and re-factoring?  Inconsistencies can in fact be left alone, it's just a simple matter of choosing your battles.  That is, how serious is the inconsistency?  Does it lead to difficulties for other team members and thus slow down the project velocity as a whole?  Or is it one of those annoyances that just gets to you?  Perhaps more importantly, evaluate the positives of not bothering with fixing an inconsistency.  The most obvious benefit, of course, is that you stay on track and the cycle continues.  In the long run, you're saving yourself many headaches too.  Think of all the potentially unnecessary work you're eliminating over the next month and how that time can be invested differently.