There are many ways in which code can be coupled, like could be ‘real’ coupling like dependencies and fan out, but also evolutionary coupling (likely to change together) and semantic similarity (doing similar things)
Developers usually modularize their software of course, and systems for that are usually hierarchical. There are two problems in the current approaches, they only give one result, and most importantly, existing clustering methods disregard existing clusters.
So, Fabian developed a visualization tool that takes into account existing modularization and can give different suggestions, for different definitions of coupling.
Fabian tried his tool on 16 open source projects and compared the existing modularization to all his options. There were three cases: In some cases (25%), the suggestion contained a perfect or almost perfect match. Great!b This was usually due to structural coupling or co-evolution.
In other cases(54%), there was only a partial match, sometimes packages needed to be merged, or sometimes they should be split.
Sometimes, there was no match at all. This happened in 21% of cases.
So in total, there usually is an explanation for the given chosen modularization, but for different reason. I think this is very interesting, and gives good insight into how a project is organized. Would different types of projects (Java? One person dev?) be typically organized differently from others?
Video of this work:
Want to read the full paper? You can!