The author never really defines "consistency" anyway. Consistency of what?

I've never seen consistency of libraries and even programming languages have a negative impact. Conversely, the situation you describe, or even going out of the way to use $next_lang entirely, is almost always a bad idea.

The consistency of where to place your braces is important within a given code base and teams working on it, but not that important across them, because each one is internally consistent. Conversely, two code bases and teams using two DBs that solve the same problem is likely not a good idea because now you have two types of DBs to maintain. Also, if one team solves a DB-specific problem, say, a performance issue, it might not be obvious how the other team might be able to pick up the results of that work and benefit from it.

So I don't know. I think the answer depends on how you define "consistency", which OP hasn't done very well.

This is where an architect is useful, because they can ask "why?"

Sometimes there is a reason! Sometimes there isn't a reason, but it might be something we want to move everything over to if it works well and will rip out if it doesn't. Sometimes it's just someone who believes that functional programming is Objectively Better, and those are when an architect can say "nope, you don't get to be anti-social."

The best architects will identify some hairy problem that would benefit from those skills and get management to point the engineer in that direction instead.

A system that requires homogeneity to function is limited in the kinds of problems it can solve well. But that shouldn't be an excuse to ignore our coworkers (or the other teams: I've recently been seeing cowboy teams be an even bigger problem than cowboy coders.)

GP is talking about "consistently bad" being worse than "inconsistently good". Not defending any inconsistency.

What you describe just sounds "inconsistent AND bad".

Ugh I remember a "senior" full stack dev coming to me with various ideas for the backend - start use typeorm instead of sequelize and replace nestjs with express, for the tickets they would work on, despite having no experience with any of these. The mess of different libraries and frameworks they left in the frontend will haunt that software for years lol.

It's essentially the same problem as https://xkcd.com/927/ [How Standards Proliferate]

I agree. It's only the foolish consistency that's problematic. A sensible consistency does, as you say, provide a coherence. William James, who overlapped Emerson, has a lot to say about positive habits.

The problem with small refactors over time is that your information about what constitutes a good/complete model of your system increases over time as you understand customers and encounter edge cases. Small refactors over time can cause architectural churn and bad abstractions. Additionally, if you ever want to do a programmatic rewrite of code, with a bunch of small refactors that becomes more difficult, with a single surface you can sometimes just use a macro to change everything all at once.

This is an example of a premature optimization. The reason it can still be good is that large refactors are an art that most people haven't suffered enough to master. There are patterns to make it tractable, but it's riskier and engineers often aren't personally invested in their codebases enough to bother over just fixing the few things that personally drive them nuts.

If improving a portion of the codebase makes it better, but inconsistent...

migrate the rest of the codebase!

Then everyone benefits from the discovery.

If that's difficult, write or find tooling to make that possible.

It's in the "if it hurts, do it more often" school of software dev.

https://martinfowler.com/bliki/FrequencyReducesDifficulty.ht...

if you have some purported improvement to a codebase that would make it inconsistent, then it's a matter of taste, not fact, whether it is actually an improvement.

I have opposite experience. Consistency is commonly enforced in bigger corporations while it's value is not that high (often negative). Lots of strategies/patterns promoted and blindly followed without a brief reflection that maybe this is a bad solution for certain problems. TDD, onion/hexagonal architecture, SPA, React, etc.

> software that has "good" and "bad" parts in unpredictable

Software that has only "bad" parts is also very unpredictable.

(Unless "bad" means something else than "bad", it's hard to keep up with the lingo)

So we should all write bad code to keep it predictable? raising the quality of the codebase is unacceptable under this premise.