2 ms·
> what if older code isn't being looked at as hard and therefore vulnerabilities aren't being discovered? It wasn’t being look at as hard before either. I don’
by MBCook 2y ago
> what if older code isn't being looked at as hard and therefore vulnerabilities aren't being discovered?
It wasn’t being look at as hard before either. I don’t think that’s changed.
They don’t give a theory for why older code has fewer bugs, but I’ve got one: they’ve been found.
If we assumed that any piece of code has a fixed amount of unknown bugs per 1000 lines, it stands to reason that overtime the sheer number of times the code is run with different inputs in prod makes it more and more likely they will be discovered. Between fixing them and the code reviews while fixing them the hope would be that on average things are being made better.
So overtime, there are fewer bugs per thousand lines in existing code. It’s been battle tested.
As the post says, if you continue introducing new bugs at the same rate you’re not going to make progress. But if using a memory safe language means you’re introducing fewer bugs in new features then overtime the total number of bugs should be going down.
- pacaro 2y agoI've always thought of this as being equivalent to "work hardening" My concern with it is more about legitimately old code (android is 20ish years old, so reasonably falls into this category) which was written using standards and tools of the time (necessarily) It requires a constant engineering effort to keep such code up to date. And the older code is, typically, less well understood. In addition older code (particularly in systems programming) is often associated with older requirements, some of which may have become niche over time. That long tail of old, less frequently exercised, code feels like it may well have a sting in its tail. The halflife/work-hardening model depends on the code being stressed to find bugs