4 ms·

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)
- tonyhart7 10mo ago
  that's why I write the first parts of my comment your example is just bad code that unpredictable
  - whstl 10mo ago
    And I disagree. My assertion is that software that has only bad parts is way more unpredictable than software that has both good and bad. For multiple reasons: because "bad" is not necessarily internally consistent. Because it's buggy. Unless, again, "bad" here means "objectively good quality but I get to call it bad because it's not in the way I like to write code".

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)

tonyhart7 10mo ago
that's why I write the first parts of my comment your example is just bad code that unpredictable
- whstl 10mo ago
  And I disagree. My assertion is that software that has only bad parts is way more unpredictable than software that has both good and bad. For multiple reasons: because "bad" is not necessarily internally consistent. Because it's buggy. Unless, again, "bad" here means "objectively good quality but I get to call it bad because it's not in the way I like to write code".