[john-tells-all]

Very interesting! I'm convinced humans looking at code plots can see things that computers can't. An extension of your idea is to show how code changes over time. Sections that don't change much = "backbone" of system, probably bug-free. New code, or code that changes a lot = "sketchy", might have bugs. Alternatively, show code colored by "quality" i.e. complexity.

Here's my take: https://github.com/johntellsall/shotglass#demo-flask-a-small...

[Weidenwalker]

Huh, I hadn't thought about it that way - you're right, infrequent changes could indeed be a good proxy for stability! (or for "dead-and-forgotten" :D)

Complexity is an interesting measure too - I'm currently not sure how we'd model this, but this could definitely help codeowners understand which parts of their codebase is currently difficult for people to wrap their heads around. Or whether there's any complex parts that there's only a single contributor to, without whom the project would be left with a serious knowledge gap.

Once this can run as part of a CI pipeline and thus lives directly in the repo, I'd also love to add an overlay with the output of the testsuite to see which parts of the codebase aren't covered by tests! Or the output of a profiler, to see which functions are actually called the most.

[john-tells-all]

Complexity is relatively easy. It's basically the number of loops and conditionals in a function :) https://thevaluable.dev/complexity_metrics_application/

The testsuite overlay sounds wonderful. Or maybe "coverage multiplied by business value". Biz-important things like authorization or money = more coverage, random marketing things = less important for test coverage.