27
What's in a Word: Consistency
Another post in this mini-series to clarify overloaded terms: This time I'll cover consistency, pronounced kənˈsɪstənsɪ, meaning "without contradictions". It originally appeared on the INNOQ blog.
The word is of Latin origin: The verb consistere means
1.: to stop, rest
2.: to consist of,
3.: to stand together.
The noun consistentia means "state of being in agreement or harmony".
From dictionary.com
In everyday language, consistent means "acting or doing something in the same way". Interestingly, besides behaviour, the noun 'consistency' also refers to the structure or content of things, and to mathematical/logical theorems.
In IT, we use the term in the following areas:
- user interfaces
- architecture and code
- ACID databases
- CAP theorem
- names and terminology
Consistency in user interfaces refers to the conformance of an UI with respect to user expectation: Software should always behave as expected, and offer actions or information in standard (consistent) ways (with the possible exception of games, which may surprise their users). For example, operations like "save file" should always be invoked with the same keyboard shortcut (such as ctrl-s). Imagine an application that, in order to save files, would require its users to press the ctrl-alt-del keyboard combo...
UI consistency refers to everything users see or do, for example, layout, colours, typography, icons/symbols, wording/naming, styling, order of things, order of actions, and required gestures or mouse clicks.
Please note that UI consistency refers to application- internal conventions and additionally to conventions provided by the operating system user interface guidelines, e.g. (see Microsoft-UIG and Apple-Mac-OS UIG for examples).
An example of quite recent inconsistencies was posted on Twitter by Zac Bowden:
In 1975, Fred Brooks wrote in his famous book Mythical Man Month:
... Conceptual Integrity is the most important consideration in system design. It is better to have a system ... reflect one set of design ideas than to have one that contains many good but independent and uncoordinated ideas."
Consistency is just another term for this conceptual integrity: Solve similar problems in similar ways to minimise surprise. Sometimes I translate consistency to tidyness or order.
In any household, you have to invest some time to keep your rooms clean and tidy. Likewise, you need to invest some time to keep your architecture and code tidy and consistent. Every single change bears the risk of introducing inconsistencies – so watch out.
When you need to inform users about internal errors, always do it in the same way. You don't want one developer to write print statements, a second one to use a logger, a third to open a GUI window, and the fourth to call system.exit with some error status code.
Within any system, apply a small set of concepts or ideas to increase understandability of code and design decisions, and to improve maintainability.
On the source code level, agreed-upon coding conventions can help write consistent code: Use the typical idioms of your favourite programming language and don't try to apply every possible language or library feature.
The old saying "less is more" applies here: less variants or less different concepts or solutions to one single problem will lead to more consistency.
In this sense, architectural and code consistency resemble simplicity: you can rarely have enough of it.
In well-established SQL databases that follow the ACID principles, consistency (the 'C' in 'ACID') relates to data integrity: Any ACID database will prevent operations that break constraints, thus ensuring data consistency.
Consistency rules in this sense could be:
- columns store only values of defines types
- unique keys remain unique after operations
- constraint checks are satisfied before and after operations
- foreign key constraints are satisfied before and after operations
If any database operation violates those or other consistency rules, the corresponding database operations or transaction will be undone (rolled back).
Consistency is inconsistently used in database and CAP (see confusing CAP and ACID wording discussions: Whereas relating to data integrity in (SQL/ACID) databases, it refers to the "atomic consistency model" in CAP CAP-Theorem revisited, meaning that any read operation is guaranteed to return to a given client the most recent write's result.
Just in case you're really interested in knowing more about consistency models – Wikipedia describes eleven (!!) different variants... way more than I want to cover here.
Did you ever stumble upon the following problems within a project:
- People using a specific term, but meaning different things by that word?
- People using different terms, all meaning the same thing?
Both variants are perfectly ok for novels, fiction and crime-movies, but too risky for software projects.
My advice: Aggressively enforce consistency within names and terms within your projects. In Domain Driven Design this rule goes by the term
ubiquitous language: identify relevant domain terminology
and clearly define their semantic, thereby ensuring a consistent use of fundamental terms within a system, its implementation and documentation.
The term consistency can have different meaning, depending on context, application or technology.
In software architecture, we gain a lot from consistently engineered and implemented systems: flexibility, understandability, maintainability and ease-of-use: It's very nice to have, and sometimes very expensive and dangerous not to...
But there's no free lunch: Consistency might be difficult to achieve, and very simple to violate.
My advice: Make consistency an explicit goal within your architectures, implementation and documentation.
Be constantly vigilant for any deviations, follow the Broken Window Theory.
Thanx for reading so far – and may you construct and build consistent systems!
Thanx to Dr. Andreas Krüger, Phillip Ghadir and Peter Hruschka for discussing consistency, conceptual integrity and the value of keeping order with me: "A tidy house, a tidy mind" - and for their constructive reviews of draft versions.
Thanx to Stefan Tilkov for references, especially concerning CAP.
27