Several of the papers referenced, at least, use empirical evidence not based on the experimental procedure you described. Eg https://www.microsoft.com/en-us/re

Several of the papers referenced, at least, use empirical evidence not based on the experimental procedure you described. Eg https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-2005-149.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/... and https://www.inf.usi.ch/faculty/lanza/Downloads/DAmb2010c.pdf https://www.inf.usi.ch/faculty/lanza/Downloads/DAmb2010c.pdf . I think the author is not saying "more bugs are found in shorter functions" but that more defects are found in software modules with shorter functions. Hypothesized reasons for this include ""interface errors"" and ""it’s plausible that creating functions will always carry some [cognitive] overhead in itself"". Even then, the only firm conclusion is for very small functions, at most a few lines long. Are those the same sorts of short functions you mean? You write: "A codebase is not a static entity." And that's true. Which is why the cited paper https://www.inf.usi.ch/faculty/lanza/Downloads/DAmb2010c.pdf https://www.inf.usi.ch/faculty/lanza/Downloads/DAmb2010c.pdf (for example) tracks repository changes for several open-source projects for several years, and correlates them with reported defects. That was used in the essay, eg, ""this is likely because we consider all bugs over the ~4 year period"". My own history is that working with code bases which follow the 'functions should be only a few lines long' approach drive me batty because I can't remember all those function names which are only used once, and because many of those code bases treat instance methods as pseudo-global variables, and modify them will-nilly. So yes, the conclusions given here agree with my personal experience, so suggest that it is a good summary of research which was reasonably well-defined. Which is a rather different conclusion that yours, yes?