I didn’t really get into it, but I think that most decisions which are not consistent are made with some feeling of “I will improve upon the existing state of this ugly codebase by introducing Good Decisions”. I’m sure even the authors of the Redux section of my code felt the same way. But code with two competing standards, only one good, is almost always worse than code with one bad standard. So breaking with consistency must be carefully considered, and the developers must have the drive to push their work forward rather than just leaving behind an isle of goodness.
You're getting a lot of pushback in the comments here and I don't understand why. This is exactly right. Stay consistent with the existing way or commit to changing it all (not necessary all at once) so it's consistent again, but better.
That’s a logic error. The claim was that "inconsistent but good" can exist, not that "inconsistent == good". Responding with one example where "inconsistent" turned out badly is a totally different claim and doesn't refute what GP says.
Who said that I only had one example? I just listed one so you'd have an idea of what I was talking about. I could give you like a hundred. This is a heuristic I've developed over a lot of time working in codebases with inconsistencies and repeatedly getting burned.
I'm not disagreeing with your example and conclusion, and I've seen many of those.
I actually agree that half-assing a problem is not the best solution.
It's just that they are not examples of "inconsistent but good". They are not even "good", just "inconsistent". You said yourself that they're worse overall.
