Software Principle #6: Consistency is King

Most personal development books will tell you to set goals and work towards those consistently.

Consistency forms habits and creates progress towards goals no matter how small.

There’s an often-quoted statistic that if you do 1% a day or get 1% better you are 37.78x closer to your goal or improved as a person.

Consistency can lead to incredible results both individually and in software.

To be clear, consistency in this sense is not referring to the CAP theorem consistency or ACID form of consistency. These are important, but also highly situational to the problem you are solving in your context.

Consistency in the Codebase

In programming, consistency is king to maintainability. Inconsistent code prevents your peers from creating appropriate mental models required to support and extend a codebase.

Even if the pattern you are using isn’t optimal, it’s better to be less-than optimal everywhere than optimal in some places and not others.

Refactoring can be done very easily on consistent codebases, but refactoring inconsistency leads to defects and faulty products. This includes consistency in our file system structure, function layout, hierarchy of objects, functions and components, documentation, and environments.

In well-patterned codebases, your peers can intuit how the codebase will behave given a certain situation- reducing time for delivering a defect fix, enhancement, and/or refactoring effort.

Since code is delivered over time, potentially over years by many developers, consistency is difficult but necessary. To keep consistency in your codebases, document patterns and where they are used in a shared knowledge repository and when you or your team has discovered a pattern that out-performs the old one, create a refactoring plan and document it.

Consistency in Architecture

In architectures, consistency allows for black boxing different systems as developers think through the entire architecture, allowing for quicker and better decisions.

This is particularly important as the scale of systems grows; without some intuition it’s arduous and time-consuming to assess and comprehend a system with seventy or more components.

An essential element to creating consistency is documenting how systems will receive input and provide output. The documentation and enforcement of interfaces, which includes encoding of both inputs/outputs, acceptable latency, size of inputs/outputs, and format of inputs/outputs will create a deeper understanding of their behavior from a high level, and how best to consume them.

Another key for generating consistency in architectures is to have strong, enforceable boundaries within the systems that are part of the architecture. Leaky behavior between components creates ambiguity and makes trying to black box any part of an architecture a daunting task.

A third way to create consistencies is to follow the first Unix philosophy: or each component should do one thing and no more than that. In monoliths, this can be more difficult than in micro services, but with strong boundaries it can be achieved.

Results of Consistency

Just like in your personal life, consistency creates better results in software. A team working on a consistent codebase and architecture will have higher performance and better outcomes than teams that don’t.

Aiming to be consistent will assist with measurement of activities and predictability of outcomes which increases the perception of quality.

Abraham Lincoln once said, “Trust is built with consistency,” and this is true for software as well. A truly consistent experience for your users will build trust in the systems that you create.

Regards,

Andrew Wolfe, CEO @Skiplist

Originally posted on https://www.skiplist.com/