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.

Consistent HTTP Codes

Does it pay in terms of security to have consistent HTTP error codes returned to the requesting clients? Does it make more sense to return an HTTP 404 when something isn't found and an HTTP 403 when something is forbidden? Or does it make more sense to always use either 404 or 403 exclusively?

How Gaphor Checks Association Ends.

With the Unified Modeling Language, comes a well defined meta model. It is this meta model that defines the semantics of the modeling elements available within the UML. An important feature of this meta model is consistency enforcement. The semantic rules defined in the UML meta model not only supply the UML modeling element but also govern how those elements may be used in relation to one another. If these rules, specified by the meta model could be verified for any given UML model, it could provide a means of ensuring a consistent model. As an example UML element that has the potential to be validated for consistency, consider the two ends of an association. One end could be a subset of the opposite end. There are a couple ways that this arrangement could go wrong. There could be missing names or there could multiplicity inconsistencies. The Gaphor UML modeling tool provides a checkmetamodel plugin that is capable of validating the association ends, as well as other potential meta model issues. This plugin can be viewed by selecting "Tools", "Check UML model". Illustrated below is the dialog that will be displayed. Only errors will be displayed here so if there is no content, the current Gaphor UML model is consistent with the Gaphor UML meta model.



When the checkmetamodel plugin validates the UML model, there are three functions involved. These functions are check_associations(), check_association_ends(), and check_association_end_subsets(). The check_association_end_subsets() function is important when validating association ends. It is the only validation that actually takes place on associations. The check_associations() and check_association_ends() functions exist for infrastructure purposes. If new functionality were to be added to Gaphor association or Gaphor association end checking, it would be placed in one of these functions. As the same suggests, the check_association_end_subsets() function will make sure that any association ends that are subsets of the opposite association end are consistent with one another. There are two basic tests to make this happen. First, the plugin will make sure that a given association end that is a subset of the opposite association end, contains names that actually exist in the opposite set. There can't be a subset property which contains elements that do not exist in the referenced set. Next, all multiplicity upper bounds in the subset need to be consistent with the upper bounds of the opposite set. This will ensure a multiplicity consistency amongst association end subsets.

With Gaphor, these meta model consistency checks are especially important because the meta model is loaded into Gaphor as any other UML model would be. If the core Gaphor UML meta model fails, there isn't much hope for any models created by users. The checkmetamodel plugin also offers potential for adding additional checking functionality.