Hacker News Reader

Comment by kerbs | Hacker News Reader

I tried GitPrime and thought it was extremely well done. If you ignore the obvious use case of management using it for bean-counting, if you work with 10, 25, 50+ developers it really reveals some enlightening patterns.

It is fairly expensive, however. Starts at around $10k/year which can make it a tough budgetary sell.

I wonder if they'll price it in with Pluralsight as a package or keep it independant.

View on HN

Might be interesting/feasible to build a GitPrime competitor and sell it for far less, making it approachable to much smaller businesses or teams. Since the data comes from git one assumes the analysis can be done asynchronously in the background, so there's no complex scalability engineering. I might well be wrong though.

Can you share a good example of the kind of interesting thing it shows?

It used some pretty interesting strategies around creating Git statistics such as the concept of seperating "new code" vs "churn". They defined churn as "modifying a line that had been previously modified in the last month" (I forgot if it was month or some other timeline).

It would chart if an engineer made a large number of "churn" diffs vs new code vs "legacy/refactoring" which was modifying code that was last touched a long time ago.

I did a trial in 2018 and liked the product a lot. There were some simple metrics like "does a developer commit code every business day" and "how long do your PRs sit waiting for review". Other more complex things they produced from the git log were statistics about churn (how often you touch the same code), and new code vs. refactoring vs. bug fixing.

Overall, I thought they handled the "you can't make metrics for developers" type objections fairly well. To get everyone on the dev team engaged and thinking about their metrics seemed like too big of a hurdle given the cost per seat of GitPrime.

Reply on news.ycombinator.com