Yep consistency truly matters, since its likely this won't be the only need for data retrieval and everyone doing their own special thing means the code becomes an unreadable, in-consistent mess that cannot fit in anyones heads and development velocity slows to a crawl.
As long as it does not deviate into getting really creative with the spec, keeping everything consistent is overrated in my opinion.
There are the exceptions of very widely used projects where contributors will only look at the code a couple times when making a change to be pushed upstream or where there are significantly junior developers that need a narrow scope of the language to help them with the learning curve and getting up to speed with the code base.
In my experience(which is very anecdotal I admit), the requirement for consistency is more about a particular personality trait that many developers have - the need for order and control - as opposed to a requirement for quality production code.
That's hardly in the hands of any one developer to make consistent, and it was hardly entirely consistent before. As long as it makes sense in the context of a given project...
Part of consistency, is being consistent with current standards. That generally means working on the code to keep it looking current.
But custom problems require custom solutions (for example, a Web shop for a customizable widget, that maybe also needs to have restrictions imposed by industry licensing standards), and that can be difficult to do, with standard stuff (I have had to do almost exactly that, and have the scars to prove it).
Also, it's local consistency is what matters, not global consistency. Developers can adjust to slightly different coding styles when they move to a new project. They're going to have to learn new abstractions, new bits of domain knowledge, and new coworker-interaction approaches anyway. Style is a very minor concern.
On the flip side, if nearby things are never updated to match changing understanding of the system, then very shortly the code will be cluttered with possibly dozens of different styles: multiple naming conventions, constants in some places, hard-coded values in others, and values read from a parameter file in others, and other kinds of variations. The result will be a chaotic scramble that has no clear structure, and requires programmers to know and understand multiple different ways of expressing the same business concept.
Yeah exactly. In all years of my experience I have seen different implementation of this which is hard to maintain. I hope this can help developers to keep their focus on the actual problems that they are solving.
Forcing consistent language, runtime, tooling etc is generally a good thing as it reduces ongoing operational burden as well as some retention & hiring dilemmas.
But in my experience striving for consistency means that before improving something you have to go and change everywhere that pattern appears in 400 different code bases going back 20 years (and all of the documentation across however many platforms). As a result nobody ever improves things.
Hard disagree. Inconsistency increases the amount of time needed for any feature and increases the likelihood of bugs. There is no upside in having to understand each individual piece of functionality from the ground up, because a lot of functionality is simply repeated in slightly different ways. What you call "hurting the capacity for developers to generalise their understanding of a system" is what I would call "building the capacity for developers to generalise their understanding of a system" - consistency is what allows for generalization.
Hmm... in my experience, stable code is more likely to be correct than code that changes often. In fact, I would consider this obvious, given that there's a non-zero chance to introduce a bug with every change.
This is true until it's no longer solving the problem. Maybe the business grows or changes and the software needs to change with them. Then the code needs to be easy to change and robust.
Again, I refer you back to the original scenario: The inconsistency is presented as accidental or unintentional, not as the first step in a cohesive long-range plan to refactor the codebase.
Alternatively, don't require strong consistency everywhere. Instead, make sure to have it places it makes sense, and always reason about it.
I view this as a generalization of optimistic locking on source control. I don't envy my past self for having to checkout code with a lock that I was going to change it.
reply