Ever since watching Adam Tornhill's excellent talk on prioritizing technical debt as if time and money matters, I've wanted a simple way to analyze my own repos. I wanted to replicate Adam's process of identifying code hotspots based on each file's code complexity, change frequency, and recency of the last change. I also wanted to see if I could recreate his "bus factor" analysis to see which files would be most adversely affected if a primary developer was hit by a bus, won the lottery, or just plain quit.
I was able to create a simplified Python version that generated the hotspot data along with other basic git log metrics. I expected some high bus factor files knowing how many initial file commits Ben made to Forem. Surely there were plenty of complicated files that only he touched!
The hotspot list shows some intuitive hotspots for a Rails app like schema.rb and routes.rb which are used to manage the database and url routing. It also shows how user.rb and article.rb are hotspots for Forem which make sense given its focus on content publishing.
So how susceptible are these hotspots to losing a team member? To analyze the bus factor, you can see how many different authors touched the file in the last 365 days.
Luckily, most hotspots have had at least 10 unique authors touch the file. This might be another big benefit of taking Forem open: many people have touched the code and that collective body of knowledge now has 20+ unique authors committing per month.
The good news is that the bus factor with Forem is low and the project should be able to weather changes in contributors.