The 80% rule, notes.
1. Yes, 80% is an arbitrary value. What matters most is that it is large enough to yield a high probability that any method chosen at random will fall below the corresponding impacted set. As this number will only be used to compare two programs, then we could just as easily have chosen 70% or 90%. We would not, however, choose a figure above 95% as impacted set seems exponentially distributed, with programs having a small amount of methods with very high impacted set, unrepresentative of the program as a whole.
Also, some might argue that most of these programs hit an impacted set of 5 close to 80%, for example, 75% of Ant's methods have an impacted set of up to 5 methods; for JUnit, 73%; for FitNesse, 70%; for Antlr, 65%. So if we'd chosen a slightly lower percentage, say 70%, then many more programs might reach an impacted set of 5 and thus be considered loosely coupled. True, but if we decrease the threshold to 70% then Netty gives an upper impacted set of just 2.5 methods, as does JGroups, and Spoiklin Soice gives 2.7 methods. This figure, then, would become the figure to beat at the 70th percentile. At the vast majority of selectable thresholds, the truly loosely coupled programs beat the others comfortably. If anything, choosing 80% flatters bad programs somewhat. back
2. This blog's taken issue with that word "coupling" before but here we're dealing with coupling on method level alone and without mentioning cohesion, so we avoid the maximization, distinctness and perspective problems. back
3. This is neither the latest version of Spring nor the version examined previously on this blog. back
4. If someone in your team is faking metrics then you've bigger problems than software. back