Appropriate vs Consistent
I stumbled across a tweet recently that got me thinking about how we apply consistency when building software applications. I think most software developers would agree that consistency is by and large a good thing. Being consistent helps us learn and understand how the code works. Code in one part of an application will work in a similar fashion to code in other parts of the application as they are “consistent”. So if we already understand how one part of the application works, we will more quickly understand how other areas work. We can then extend this analogy across different applications, domains and even technologies.
However, we shouldn’t slavishly follow these patterns just for the sake of consistency. We also need to bear in mind what is appropriate. What may have worked and been appropriate in one part of the application may not be appropriate for other parts of the application. In such cases it is perfectly acceptable to be inconsistent.
Like standards, being consistent sets out guidelines and general modes of operation and structure. These enable us to develop our applications in such a way that they reuse modes of operation and structure that went before. But that doesn’t necessarily imply that all future development going forwards will benefit from these modes of operation and structure. In fact, the exact opposite may be true.
Balance is needed. Whilst consistency is certainly a good thing, doing it for its own sake at the expense of what is appropriate will lead to poorly constructed software. And this is where experience comes into play. To be able to weigh up the pros and cons of each possible solution, and find the one that fits best. There is no rule of thumb here. Where consistency and appropriatenesstrade off each other will depend entirely on the merits of the specifics of the application.
So when building that shiny new application, just bear in mind that you aren’t slavishly being consistent, and that you need to balance consistency with what is appropriate.
