Consistency is NOT the most important thing. Correctness is. This guy has been in the trenches flinging shit too long. I work with vendors and do my best to use the subset of their product that actually works correctly. I don’t want new features to work like shit just because the old ones did too.
Consistency is NOT the most important thing. Correctness is.
What point do you think you’re making? I mean, do you think anyone looks at a PR and says “this PR is clearly wrong, but it’s so consistent that I must approve it.” That’s obviously not the point, is it?
I’ve definitely seen “this is more correct, but all the other code does it like this so can you change it?”
I can’t say I entirely disagree with it either - usually the “more correct” is not “the existing code doesn’t work at all”, and keeping it consistent makes it easier to fix all of the code later, because you’re only fixing one style instead of two (or more).
I found the title of that section slightly triggering too, but the argument they lay down actually makes sense. Consistency helps you to achieve correctness in large codebases, because it means you don’t have to reinvent what is correct over and over in separate pockets of the codebase. Such pockets also make incremental improvements to the codebase harder and harder, so they do come back to bite you.
Your example of vendors doesn’t relate to that, because you don’t control your vendor’s code. But you do control your organisation’s.
Consistency as a means to correctness still means correctness is the more important aspect. Far too many projects and people that go hard on some methodologies and practices lose sight of their main goal and start focusing on the methods instead. Even to the point were the methods are no longer working toward the goal they originally set out to accomplish.
Always have the goal in mind, once your practices start to interfere with that goal then it is time to rethink them.
Consistency is NOT the most important thing. Correctness is. This guy has been in the trenches flinging shit too long. I work with vendors and do my best to use the subset of their product that actually works correctly. I don’t want new features to work like shit just because the old ones did too.
What point do you think you’re making? I mean, do you think anyone looks at a PR and says “this PR is clearly wrong, but it’s so consistent that I must approve it.” That’s obviously not the point, is it?
I’ve definitely seen “this is more correct, but all the other code does it like this so can you change it?”
I can’t say I entirely disagree with it either - usually the “more correct” is not “the existing code doesn’t work at all”, and keeping it consistent makes it easier to fix all of the code later, because you’re only fixing one style instead of two (or more).
I found the title of that section slightly triggering too, but the argument they lay down actually makes sense. Consistency helps you to achieve correctness in large codebases, because it means you don’t have to reinvent what is correct over and over in separate pockets of the codebase. Such pockets also make incremental improvements to the codebase harder and harder, so they do come back to bite you.
Your example of vendors doesn’t relate to that, because you don’t control your vendor’s code. But you do control your organisation’s.
Consistency as a means to correctness still means correctness is the more important aspect. Far too many projects and people that go hard on some methodologies and practices lose sight of their main goal and start focusing on the methods instead. Even to the point were the methods are no longer working toward the goal they originally set out to accomplish.
Always have the goal in mind, once your practices start to interfere with that goal then it is time to rethink them.
I’m not arguing against that. Merely providing some counterweight to the idea that the author was “flinging shit in the trenches” 😅