Notes on this chapter of what seems to be a book on "software evolution".
"The defects we measure from history can only be mapped to components because they have been fixed." That seems rather optimistic...
"This mistake manifests itself as an error in some development artefact, be it requirements, specification, or a design document." This is getting concerningly software-engineering-ish...
Sort of weird that everything is module-scoped. I guess it makes sense for very large systems, but I'd tend to think of things more on the function / basic-block level.
Also weird that all of their coupling metrics (except class coupling) are for global variables. Any / all shared state is a potential bug source; global just happens to be the most egregious possible case (except for system-globals, like files on disk and registry entries...).
"Never blindly trust a metric." Wiser words are rarely written.
Not a whole lot of surprises. Typical complexity metrics correlate with bugs. Churn correlates with bugs. Tricky problem domains correlate with bugs (though I feel like their example of Eclipse compiler internals vs GUI is sort of disingenuous; if the compiler internals are a little broken, Eclipse cannot perform its core function, but if the UI is a little broken, often end users can work around it or just live with it. So is it a function of the inherent difficulty of the problem domain, or the centrality of that problem domain to the function of the project?). Buggy dependencies correlate with bugs, but fall off with distance. Would've been interesting to see the d=4 case for "domino effect in Windows Server 2003".
Sort of bummed that their references weren't included.