[1/*] If we take the chance that a tool (compiler, linker, batch, whatever) remains working for a particular codebase after one year as a given probability p, then the chance that build remains working after x years is p^xn, where n is the number of tools used in the build.
-
Show this thread
-
Replying to @cmuratori @JoshuaBarczak
This assumes that the probability of a tool failing in any given year is the same, but that's almost certainly not true is it? Something is much more likely to break in the first year (or first month) than it is in year 10.
2 replies 0 retweets 2 likes -
Replying to @ssylvan @JoshuaBarczak
At this risk of stating the obvious, _that is what a probability assignment is_. Just pick the average probability, whatever you're comfortable with. For these kinds of graphs you do not need to model the behavior you're talking about, it doesn't matter.
1 reply 0 retweets 8 likes -
Replying to @cmuratori @JoshuaBarczak
While I agree with the general "long tail" issue you're describing, I don't think I agree that this behavior doesn't matter. It absolutely does. If most tools fail in the first month vs if it fails with uniform probability over ten years, makes a huge difference.
1 reply 0 retweets 1 like -
In the former case, you can try something and if it doesn't work out you've only lost a month's worth of stuff built on top of it. In the latter, you could have years worth of stuff built on top.
1 reply 0 retweets 0 likes -
So once you take that into account, the simple exponential graphs you make don't really match reality anymore, because the flaky tools get pruned early and stop causing issues.
1 reply 0 retweets 0 likes -
Replying to @ssylvan @JoshuaBarczak
We definitely don't live in that reality, so I'm not sure I'm that concerned about it :) But in general these graphs actually paint a much rosier picture than they should, even so. If you actually wanted to measure failure rates, it has to be pair-wise.
1 reply 0 retweets 4 likes -
So at the point where you want to accurately model software failure, you have to make a much more complicated model, that is true.
1 reply 0 retweets 5 likes -
Replying to @cmuratori @JoshuaBarczak
So on the one hand, lots of software just sits dormant and keeps working year after year without bothering anyone. On the other hand, I intuitively and experientially agree with you that accumulating dependencies is bad for stability. Not sure about the math like that though.
2 replies 0 retweets 2 likes -
Replying to @ssylvan @JoshuaBarczak
I mean I think honestly the basic equation does pretty much tell you that, though. In my experience, things with no dependencies written in old languages (ergo, the language isn't a dependency) tend to "just work". Things in evolving languages with lots of dependencies don't.
2 replies 0 retweets 4 likes
While the real model is much more complicated than what I graphed, I'm pretty sure that the underlying concept of exponential probability is inescapable, honestly, so whatever the real graph does look like, it basically does something like this.
-
-
Replying to @cmuratori @JoshuaBarczak
I'd say sub-exponential, but also super-linear. There's a related problem with large software (e.g. android). Where every team/component targets a certain (low) bug rate, but as the number of teams/components increase the probability that a user has a bug-free experience drops.
1 reply 0 retweets 0 likes -
So the general point about people mis-valuing the cost of dependencies (or features) I very much agree with, and it shows up all the time.
0 replies 0 retweets 1 like
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.