My first actual article on this site was explaining my take on three tiers of consistency within software and assuring that a software program provides an experience where a user can expect things to be consistently intuitive and behave based on the user’s expectations.
Consistency in the Waterfall
Putting on the old man costume, one might muse a bit about the good old days of waterfall software development when everything worked out perfectly because we had reams of specifications for each project. The specifications must be right because they had sign-off by someone important and we had a big stack of change control paperwork for each modification!
Stepping off the sarcastic soapbox for a moment, I will note that implementing consistent behavior wasn’t likely easier in the waterfall days, but it was probably less ambiguous. One could always look up requirement 220.127.116.11 where it specified how something should work and compare the software to the letter of the requirement.
The Agile Consistency Dilemma
When we transition to a more agile way of building software, where we value
Working software over comprehensive documentation
how do we ensure consistency in the absence of pile of specifications?
Consistency by Communication and Familiarization
Looking at the three aspects of consistency I wrote about previously, we have:
- Consistency within a given application
- Consistency across applications within the line of business
- Consistency with industry norms and trends
Within an application or across a line of business, we can help facilitate consistency by enabling and facilitating communication within the development team. Developers that chat and communicate about how they’re solving problems are likely to solve those problems in similar fashion.
Familiarization with products can help prevent reinvention of the wheel. If your company has six products, a developer ought to have end-user knowledge of all six such that when implementing a new feature they would know how that feature, interface, or workflow might already be in place in a different program. This seems like it would be obvious, but I can recall several cases where I’ve raised an issue of inconsistency across products (by the same organization) and the developer indicated that he or she had never seen that other product.
Consistency failures are often failures of innocent ignorance… the developers aren’t being inconsistent with intent. They’re being inconsistent because they aren’t aware. Increasing awareness increases the consistency.
Take that day or two that you might have spent reviewing specifications and go work with the software.
As an added bonus, that time spent communicating about consistency? Your developers will also communicate about other things and build a more cohesive team.