4 ms·

It doesn't really matter to me if the study is factual, because it is not about whether this study actually took place. It is not even about having a general la

It doesn't really matter to me if the study is factual, because it is not about whether this study actually took place. It is not even about having a general law that bugs are always more expensive to fix in production. It's just an idea that you can use in an argument. When you invoke this idea, what you are actually saying is: "I want to prioritize this bug now, because my experience tells me it will save cost and/or effort." You use this rhetorical device to put weight behind your argument. It's like invoking "80/20 principle" or "technical debt". Maybe I've become cynical but the longer I've been working, the more I like the postmodern theory that almost everything is a language game. I start to recognize bullshit, and to recognize when it's the right time to use BS myself. (Not saying that truth doesn't matter. Just that sometimes you have a correct but not convincing point, and you can support it with a not-100%-scientifically correct, but more convincing point.)

piva00 5y ago
> Maybe I've become cynical but the longer I've been working, the more I like the postmodern theory that almost everything is a language game. I start to recognize bullshit, and to recognize when it's the right time to use BS myself. (Not saying that truth doesn't matter. Just that sometimes you have a correct but not convincing point, and you can support it with a not-100%-scientifically correct, but more convincing point.) After 17 years of career I can relate to this feeling, at least the start of it. I'm not at the point where I can safely evaluate when it's the right time to bullshit myself, as a way to avoid putting effort on convincing someone about intuitive feelings I have, from all my accumulated experience, on why something is good or bad to do. I'm still at the stage where I pick my battles instead of trying to use language to empower an argument I feel strong about, I'm still too "naive and honest" and would feel it's wrong to do it. But fucking hell, how many discussions I have simply avoided or jumped out because it would take too much energy and time to explain to someone that's been too stubborn or sure about some solution or process. I have much less patience for these, I got more in the mode of "show, don't tell" and if I feel I don't have energy for a quick demo I know it's not a battle worth of my time. I think I'm still too much of a modernist and seeking truth...
Cthulhu_ 5y ago
And while 100x might not be true, you KNOW it's a lot more damaging, costly, and disruptive to have to fix a bug that makes it way to production - arguments in favor of testing, canary releases, code reviews, robust programming languages and architectures, etc. They won't stop all issues, but the less that make it to production the better. That one doesn't take language games or political games, I think. It shouldn't anyway.
- indymike 5y ago
  > you KNOW it's a lot more damaging, costly, and disruptive Maybe. It certainly is more damaging to the ego, but ego is cheap. Bugs are not all created equal and have different costs to fix, and different affects on the business. For example, and architectural mistake will cost a lot to fix and can be exploited by competitors to take customers. A tiny logic error might take 5 minutes to fix, and affect a small number of users and have zero impact on the overall business. There's also tiny bugs that cost a lot (oops decimal in wrong place on bills)...
  - rauljara 5y ago
    I don’t disagree with the maybe, because of course some bugs really aren’t that bad. But especially in the case of those architectural bugs, it is incredibly difficult to be confident that the impact of the bug is as limited as you think it is. Additionally, if you couldn’t take the time to fix it in dev, it is also pretty likely that it will live in production for a long time, possibly forever. And these bugs have a habit of prompting code smelly workarounds, interacting with other bugs, and generally making your system harder to reason about. It could be the right decision to not fix an architectural bug. But it is a gamble, with a very long tail of cost for getting it wrong.
- tibbetts 5y ago
  Lots of bugs in production code never get triggered or never get fixed and lots of production code eventually gets deleted. There is a real problem with confirmation bias here, as the bugs that cost weeks to fix in production are extremely memorable, and the bugs you might have thought would be a big deal but never actually had to deal with are nearly invisible.
JumpCrisscross 5y ago
> It's like invoking "80/20 principle" Power law dynamics are empirically demonstrable. There are lots of conventions experts collect around that evidence later proves to be false.
TheRealPomax 5y ago
If the idea isn't based on fact, you can't use it in an argument if you want the other side to believe you. Making up facts doesn't make them true. That's the whole point. You can give anecdotes, sure, and enough anecdotes makes for a likely story, but unless you or someone else puts in the work to test that story, it's still just a story.
- chadwittman 5y ago
  Stories are nearly equal in convincing someone to believe you. Just look at US Politics right now to see that we live in a post-truth society that strongly values narrative.
  - TheRealPomax 5y ago
    so... you made my point for me? "Stories are convincing even if they're entirely baseless"? They convince those who don't care about whether something is true, and so... we should roll with that? How is that an acceptable attitude? No, stories are stories, they're the thing snake oil sellers sell the masses in order to sell their snake oil: put them to the test. If their story is a good story: write it down and then go "cool, so what whether this actually has any merit, or truth?". This isn't Orwell's 1984, just because people like something doesn't mean it's even remotely trustworthy. Let alone pandering to.
- captainmuon 5y ago
  I'm not saying you should make up lies. If you want to tell somebody that persistance is important, you can say "constant dripping wears away the stone", and they will understand the metaphor. It doesn't matter that this is not true for every stone or that you haven't done the experiment yourself.

piva00 5y ago

> Maybe I've become cynical but the longer I've been working, the more I like the postmodern theory that almost everything is a language game. I start to recognize bullshit, and to recognize when it's the right time to use BS myself. (Not saying that truth doesn't matter. Just that sometimes you have a correct but not convincing point, and you can support it with a not-100%-scientifically correct, but more convincing point.) After 17 years of career I can relate to this feeling, at least the start of it. I'm not at the point where I can safely evaluate when it's the right time to bullshit myself, as a way to avoid putting effort on convincing someone about intuitive feelings I have, from all my accumulated experience, on why something is good or bad to do. I'm still at the stage where I pick my battles instead of trying to use language to empower an argument I feel strong about, I'm still too "naive and honest" and would feel it's wrong to do it. But fucking hell, how many discussions I have simply avoided or jumped out because it would take too much energy and time to explain to someone that's been too stubborn or sure about some solution or process. I have much less patience for these, I got more in the mode of "show, don't tell" and if I feel I don't have energy for a quick demo I know it's not a battle worth of my time. I think I'm still too much of a modernist and seeking truth...

Cthulhu_ 5y ago

And while 100x might not be true, you KNOW it's a lot more damaging, costly, and disruptive to have to fix a bug that makes it way to production - arguments in favor of testing, canary releases, code reviews, robust programming languages and architectures, etc. They won't stop all issues, but the less that make it to production the better. That one doesn't take language games or political games, I think. It shouldn't anyway.

indymike 5y ago
> you KNOW it's a lot more damaging, costly, and disruptive Maybe. It certainly is more damaging to the ego, but ego is cheap. Bugs are not all created equal and have different costs to fix, and different affects on the business. For example, and architectural mistake will cost a lot to fix and can be exploited by competitors to take customers. A tiny logic error might take 5 minutes to fix, and affect a small number of users and have zero impact on the overall business. There's also tiny bugs that cost a lot (oops decimal in wrong place on bills)...
- rauljara 5y ago
  I don’t disagree with the maybe, because of course some bugs really aren’t that bad. But especially in the case of those architectural bugs, it is incredibly difficult to be confident that the impact of the bug is as limited as you think it is. Additionally, if you couldn’t take the time to fix it in dev, it is also pretty likely that it will live in production for a long time, possibly forever. And these bugs have a habit of prompting code smelly workarounds, interacting with other bugs, and generally making your system harder to reason about. It could be the right decision to not fix an architectural bug. But it is a gamble, with a very long tail of cost for getting it wrong.
tibbetts 5y ago
Lots of bugs in production code never get triggered or never get fixed and lots of production code eventually gets deleted. There is a real problem with confirmation bias here, as the bugs that cost weeks to fix in production are extremely memorable, and the bugs you might have thought would be a big deal but never actually had to deal with are nearly invisible.

JumpCrisscross 5y ago

> It's like invoking "80/20 principle" Power law dynamics are empirically demonstrable. There are lots of conventions experts collect around that evidence later proves to be false.

TheRealPomax 5y ago

If the idea isn't based on fact, you can't use it in an argument if you want the other side to believe you. Making up facts doesn't make them true. That's the whole point. You can give anecdotes, sure, and enough anecdotes makes for a likely story, but unless you or someone else puts in the work to test that story, it's still just a story.

chadwittman 5y ago
Stories are nearly equal in convincing someone to believe you. Just look at US Politics right now to see that we live in a post-truth society that strongly values narrative.
- TheRealPomax 5y ago
  so... you made my point for me? "Stories are convincing even if they're entirely baseless"? They convince those who don't care about whether something is true, and so... we should roll with that? How is that an acceptable attitude? No, stories are stories, they're the thing snake oil sellers sell the masses in order to sell their snake oil: put them to the test. If their story is a good story: write it down and then go "cool, so what whether this actually has any merit, or truth?". This isn't Orwell's 1984, just because people like something doesn't mean it's even remotely trustworthy. Let alone pandering to.
captainmuon 5y ago
I'm not saying you should make up lies. If you want to tell somebody that persistance is important, you can say "constant dripping wears away the stone", and they will understand the metaphor. It doesn't matter that this is not true for every stone or that you haven't done the experiment yourself.