Hacker News Reader

Comment by PaulRobinson | Hacker News Reader

`sudo rm -rf /` is a very big thing to do in a very small amount of code, sure. I'd adovocate thinking about probabilities then:

If you have a shorter period of time to produce a smaller change, are you more or less likely to have a smaller blast radius than if you have a longer period of time to produce a much larger change?

There are no absolutes, but we're talking about risk here, and risk is about impact and _likelihood_. Your impacts are going to be smaller and your likelihood of big blast radiuses are _less likely_, but not ruled out.

View on HN

I’d say that change duration is irrelevant to blast radius, because bug impact is independent of code size.

Having said that - a smaller piece of code is easier to understand, so there is more potential to notice problems.

However that depends on whether you do that diligence. And the dangerously false belief that the blast radius is going to be smaller because of change size rather than understanding works against you.

I don't know whether a smaller change means necessarily a lower probability of small blast radius, but the larger a code change is the higher the probability is of a high blast radius. Blast radius isn't necessarily going to be smaller because of change size, but the chance of it being smaller certainly does decrease in relative terms as it becomes smaller even if it never reaches zero and is still in absolute terms quite high. It's still a noticeable improvement and because of that still a worthy goal to pursue, nevermind the ancillary improvements to product/design/engineering/business coordination and delivery volume as a result of lower iteration cycle time. That's the larger win for me.

The chance per change size may be reduced, but you are are going to more changes, so the overall probability is unaffected.

I think blast radius is basically

    bug size * mean time to recovery

Further I believe bug size is usually proportionate to change size, and MTTR is a function of how long it takes to get a change out into user’s hands

So if you release early, release often and keep an eye on your metrics, you stand a good chance of your blast radius being consistently low.

You won’t eliminate it, you’ll just be beating the team with rare and large releases that take an age to get through their release process.

Of course, if you can take your time and make small changes slowly, but release them quickly, you’re now doing even better, but there are few businesses where that’s economically viable: competitors will just get to product market fit quicker than you will.

It would be interesting if you could unpack why you believe this formula?

What is the underlying mechanism that makes it so?

If you assume that any and every change could have a disastrous effect, would you rather have to deal with one change at a time or many changes at a time?

I’d rather people not think that the risk is lowered because of the code size.

It’s a red herring. Risk is lowered because the code is understood better not because the code is smaller.

The assumption that each change carries an equal risk of disaster isn’t valid, because risk depends on your understanding of the changes and the codebase.

Risk is equal only in the case where the developers know nothing about the change or the codebase. In this case, fire the VP of engineering or equivalent.

Making changes as a series of small increments can just as easily lead to less understanding of the overall impact of the changes than a larger design process. Then you get a nice big failure from a small change. It looks like most of the changes were harmless when in fact they were all just building towards the one that caused the failure.

Reply on news.ycombinator.com