The further along we get building views like Commit Browser or File Browser, the more apparent it becomes that the future of commit browsing is graphical. Text was fine for v1, but for v2, we've got to make this stuff fun to use -- to whatever extent that is possible with developer tools, anyway. We want to maximize for geek-joy factor.

Many developers who discover GitClear have come out of desperation. They just need to quickly visualize where activity is happening in a library. Or they need a time-efficient way to know what features are coming down the pipe in their dependencies (gems, libraries, packages, internal, etc). They haven't thought much about code measurement. They know that using lines of code to measure is bull...oney. They might know "commits made" an order of magnitude better than lines of code, but still very noisy. Beyond that, they never needed to think much about measurement.

linkA benefit with a catch?

And this is where it may suddenly dawn on new users... for GitClear to provide rich visual tools, commit activity has to be quantified. Which requires that commits are assigned numbers. Which implies that individual developers could have numbers applied to their work. Suddenly, this tool that had flown in on the coattails of desperation is trying to reduce the rich world of developer activity to a set of numbers. What gives?

The nut of conflict is that, in one form, Line Impact provides a necessary window into developer activity. Compared to what came before it, GitClear offers a very different way to see the world.

But, in the other form, that same number could be twisted to declare "winners" and "losers" based on what seems like an arbitrary-ish metric. That's not fair.

As the creators and longtime dogfooders of this metric, we've become intimately familiar with the pattern that follows adoption of Line Impact. The first step after excitement is concern. Let's jump into that concern headlong and see where it leads.

linkFace down the fear

When developers weigh out the "utility" vs "peril" of code measurement, which triumphs? The utility of visualizing code is readily apparent through examples like those featured in the footnotes above (or our blog). The peril is if Line Impact will be used to judge those who reside in its southern percentiles. If we can prevent managers from using Line Impact to draw misguided conclusions, we can diminish the peril.

Thankfully, as the creators of Line Impact™️, we get to have many (so many) conversations with managers about how to use it. Here's the gist of what we tell them:

Line Impact doesn't measure productivity. And it certainly doesn't measure what makes a great developer. What it does is provide a concise and configurable way to approximate how much a set of commits evolves the code base. There are 1,000 ways that a developer can provide value without directly evolving the code base, just as there are many destructive ways they might evolve the code base.

-- Bill Harding, GitClear CEO, August 2019

Ok, so Line Impact can't measure whether the developer is working on the tasks they were assigned. It can't measure code quality (yet). It can't measure whether the developer was paying down tech debt (yet). There are lots of things it can't hope to ever measure. Thankfully, to improve clarity within git, we don't need to answer such hard questions. We just need to approximate the evolution that a set of commits confers, and bend that into pictures that best tell the story of what's happening in a repo over time.

open_in_new

Line Impact of Ruby on Rails charted over its history. Many adopted it during the 2008 upswing. The upgrade from 1->2->3 was palpable, each evolving broad swaths from the previous version

But let's be honest. Just because the creators say Line Impact can only measure a specific strain of progress, that doesn't mean that some managers won't try to twist it to some other use. After all, GitClear is a business that gets paid by companies seeking a clearer idea of what's happening in their repos. Presumably some of these companies will be haunted by managers who can't grasp the nuance of what Line Impact isn't.

We can't prevent lazy managers from having bad ideas. It's kind of their MO 🤷‍♂️. But we can:

The payoff for these inconveniences? Time-saving visualizations that aren't otherwise possible. Yes please.

linkWhat can Line Impact teach?

To this point, we've focused on drawing the boundaries of what Line Impact can measure. What if we invert selection? What can Line Impact tell us besides "how much a set of commits evolved the code base"?

To allow Line Impact to assume the shape of whatever technology it's tasked to analyze, it had to be built on a base of flexible assumptions. A happy side effect of this flexibility is that Line Impact can be tuned to incentivize your team's aspirations. Maybe that's writing more tests, creating better documentation, reducing overall code footprint... whatever sort of goals your team might want to set, Line Impact can reflect how rapidly the team is moving toward them.

If that sounds too abstract, consider a developer archetype that benefits from assisted code clarity:

linkAvid Andrew

Avid Andrew graduated Aabcelerator Academy with flying colors, but seems to have started slow in his new job. Currently his preference is to work in view code, since he can make progress most quickly there and it's fun to work on something that he can see at the end of the day.

Andrew wants to see what code conventions are being used in recent view code, but it's not apparent where the bulk of the recently written code lives within his huge legacy project. The Directory Browser is a very convenient way for Andrew to orient himself and get up to speed quickly with the most active areas of development:

open_in_new

Directory Browser visually guides a developer in whichever part of a project their interest lies

linkToward developer measurement of greatest shared benefit

Various data sources claim that the demand for new developers is increasing by ~20% yearly. That is a deluge of incoming talent. The strength of these incoming reinforcements increases to the extent they've pursued software development as a hobby prior to joining their first production team.

But for a new developer, the world of code starts as a disorienting place. Even experienced developers entering a new repo take time to get their bearings. Where does most of recent code reside in a legacy project? Where are the weak points that shoulder the team's tech debt? Who was principally responsible for building the [whatever]? Which developers might serve as role models for writing view code? What tools are they using?

For new developers, GitClear can be a compass. It helps answer every question above. If desired, GitClear can help guide new developers toward a niche where they'll thrive. Most importantly, it makes it easier for them to survey the landscape of what's happening in a repo. Just as most great writers spend time every day reading, most great coders I've known spend time every day reviewing code. The sooner new developers get in this habit, the better..!

In spite of the proliferation of developer measurement tools like Velocity, Pinpoint, GitPrime, et. al, the space has somehow yet to yield tangible benefits to the developers themselves. Pinpoint and GitPrime in particular are enterprise management tools. They act as a manager's "little helper" that is generally inaccessible to the developers themselves.

The next generation of developer measurement can do better. In a good case scenario, GitClear will push everyone forward on that front.

The opportunity in second-generation dev measurement tools is that the benefits can extend from VP of Engineering down to the developers themselves, especially new developers. Today, browsing code is so tedious that we lose hobbyist developers. If we just made it more fun to see what a successful open source contribution looks like, maybe more people would try it? 🤞