4 ms·

Do we even need a study for this? Production means you have limited time to make changes on there. It’s like when they went to that planet in Interstellar where

Do we even need a study for this? Production means you have limited time to make changes on there. It’s like when they went to that planet in Interstellar where each second represents a day. Time is money, you age fast on production. It will obviously be more expensive.

tgv 5y ago
At the risk of derailing the discussion even further, I'd say: yes, we do. There's quite a difference between 1.25x and 100x more expensive, especially if you're building the next AWS. However, such a number would need to be conditioned. I can imagine that fixing an error in the i9 microcode will be a lot costlier to fix in "production" than your average NaN JS bug.
AmericanChopper 5y ago
That’s an intuitive explanation for why the claim might be true. An intuitive explanation for why the claim might not be true is that production has your entire user base testing it in real time. Recreating, diagnosing, and collecting feedback on a fix would be much cheaper. Of course that doesn’t necessarily account for the expense to your customers. Which is why it’s important to have both a specific explanation for what a claim is claiming, and some empirical verification to back it up. This claim seems to have neither.
ordu 5y ago
Yes, we need to study this. "Obviously" is not good enough. People want to find the best use for their time, to get maximum profits. An optimization can be done for some extent by relying on "obvious", but if really you want to maximize productivity, you need to measure things. You need to go from qualitative reasoning to quantitative one. We need not just measure comparative costs of bugs in productions with bugs in development, we ways to measure amount of not found yet bugs, we need to predict speed of bug-hunting in advance, we need a lot of tools to really quantify a development process. To make a decision we need a way to predict future events, it allow to compare consequences of different decisions and to choose one wisely. > Time is money, you age fast on production. Bugs is also money. So we need a way to compare them quantitatively.

tgv 5y ago

At the risk of derailing the discussion even further, I'd say: yes, we do. There's quite a difference between 1.25x and 100x more expensive, especially if you're building the next AWS. However, such a number would need to be conditioned. I can imagine that fixing an error in the i9 microcode will be a lot costlier to fix in "production" than your average NaN JS bug.

AmericanChopper 5y ago

That’s an intuitive explanation for why the claim might be true. An intuitive explanation for why the claim might not be true is that production has your entire user base testing it in real time. Recreating, diagnosing, and collecting feedback on a fix would be much cheaper. Of course that doesn’t necessarily account for the expense to your customers. Which is why it’s important to have both a specific explanation for what a claim is claiming, and some empirical verification to back it up. This claim seems to have neither.

ordu 5y ago

Yes, we need to study this. "Obviously" is not good enough. People want to find the best use for their time, to get maximum profits. An optimization can be done for some extent by relying on "obvious", but if really you want to maximize productivity, you need to measure things. You need to go from qualitative reasoning to quantitative one. We need not just measure comparative costs of bugs in productions with bugs in development, we ways to measure amount of not found yet bugs, we need to predict speed of bug-hunting in advance, we need a lot of tools to really quantify a development process. To make a decision we need a way to predict future events, it allow to compare consequences of different decisions and to choose one wisely. > Time is money, you age fast on production. Bugs is also money. So we need a way to compare them quantitatively.