5 ms·

> For instance: In large codebases, consistency is more important than “good design” But this is exactly the type of generic software design advice the article

• karmakaze 10mo ago
  Yeah that line gave me a twitch. Reading on though it's more about the resulting coherence and correctness rather than like the Ralph Waldo Emerson quote: "A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines."
  • kayo_20211030 10mo ago
    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.
• johnfn 10mo ago
  I don’t know. At my place a lot of cowboy engineers decided to do things their own way. So now we have the random 10k lines written in Redux (not used anywhere else) that no one likes working with. Then there’s the part that randomly uses some other query library because they didn’t like the one we use in 95% of the code for some reason, so if you ever want to work with that code you need to keep two libraries in your head instead of one. Yes, the existing query library is out of date. Yes, the new one is better— in isolation. But having both is even worse than having the bad one!
  • shayway 10mo ago
    It's essentially the same problem as https://xkcd.com/927/ https://xkcd.com/927/ [How Standards Proliferate]
    • eviks 10mo ago
      So following that silly comic you'd ban utf-8 because it breaks consistency? (even though in reality it beat most other standards, not just became 15th)
      • deleted 10mo ago
        [deleted]
  • benoau 10mo ago
    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.
  • whstl 10mo ago
    GP is talking about "consistently bad" being worse than "inconsistently good". Not defending any inconsistency. What you describe just sounds "inconsistent AND bad".
    • johnfn 10mo ago
      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.
      • deleted 10mo ago
        [deleted]
      • whstl 10mo ago
        I don't know what to say. 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.
        • johnfn 10mo ago
          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.
          • whstl 10mo ago
            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.
  • roguecoder 10mo ago
    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.)
  • yunnpp 10mo ago
    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.
• pydry 10mo ago
  Moreover, saying that consistency is more important than good design is like saying that eating leafy greens is more important than a good diet.
• Waterluvian 10mo ago
  I feel like “be consistent” is a rule that applies very broadly. There’s absolutely exceptions and nuances. But I think when weighing trade-offs, program makers by and large deeply under-weigh being consistent.
  • Sankozi 10mo ago
    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.
• tonyhart7 10mo ago
  Yeah its called the expectations, consistently bad is predictable software that has "good" and "bad" parts in unpredictable
  • redrove 10mo ago
    So we should all write bad code to keep it predictable? raising the quality of the codebase is unacceptable under this premise.
    • tonyhart7 10mo ago
      "So we should all write bad code to keep it predictable?" its true and false at the same time, it depends here I can bring example: you have maintaining production system that has been run for years there is flaw in some parts of codebase that is probably ignored either because 1. bad implementation/hacky way 2. the system outgrow the implementation so you try to "fix" it but suddenly other internal tools stops working, customer contact the support because it change the behaviour on their end, some CI randomly fails etc software isn't exist in a vacuum, complex interaction sometimes prevent "good" code to exist because that just reality I don't like it either but this is just what it is
    • evilduck 10mo ago
      Possibly. Probably even. High quality and consistent > Low quality and consistent > Variable quality and inconsistent. If you're going to be the cause of the regression into variable quality and inconsistent you'd better deliver on bringing it back up to high quality and consistent. That's a lot of work that most people aren't cut out for because it's usually not a technical change but a cultural change that's needed. How did a codebase get into the state of being below standards? How are you going to prevent that from happening again? You are unlikely to Pull Request your way out of that situation.
  • whstl 10mo ago
    > 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)
• snoman 10mo ago
  My reading of it also violates the Boy Scout Rule. That is to say: if improving some portion of the codebase would make it better, but inconsistent, you should avoid the improvement; which is something that I would disagree with. I think adherence to “consistency is more important than ‘good design’” naturally leads to boiling the ocean refactoring and/or rewrites, which are far riskier endeavors with lower success rates than iterative refactoring of a working system over time.
  • jpollock 10mo ago
    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.html https://martinfowler.com/bliki/FrequencyReducesDifficulty.ht...
  • johnbcoughlin 10mo ago
    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.
  • CuriouslyC 10mo ago
    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.
  • strogonoff 10mo ago
• jpollock 10mo ago
  This isn't really about software quality, it's about the entire organization. Consistency enables velocity. If there is consistency, devs can start to make assumptions. "Auth is here, database is there, this is how we handle ABC". Possible problems show up in reviews by being different to expectation. "Hey, where's XYZ?", "Why are you querying the database in the constructor?" Onboarding between teams becomes a lot easier, ramp up time is smaller. Without consistency, you end up with lots of small pockets of behavior that cause downstream problems for the org as a whole. Every team needs extra staff to handle load peaks, resulting in a lot of idle devs. Senior devs can't properly guess where the problematic parts of fixes or features would be. They don't need to know the details, just where things will be _difficult_. Every feature requires coordination between the teams, with queuing and prioritizing until local staff become available. Finally, consistency allows classes of bugs to be fixed once. Fix it once and migrate everyone to the new style.
• Night_Thastus 10mo ago
  Consistency is best, with a slow gradual, measured movement towards 'better' where possible. When and where the opportunity strikes. If you see a massive 50 line if/else/if/else block that can be replaced with a couple calls to std::minmax, in code that you are working on, why not replace it? But don't go trying to rewrite everything at once. Little improvements here or there whenever you touch the code. Look for the 'easy wins' which are obvious based on more modern approaches. Don't re-write already well-written code into a new form if it doesn't benefit anything.