Developer Productivity: why version control matters
The conversation of measuring developer productivity includes many variables. One of those is version control (VC). Simply put, VC is a way to keep track of previous versions of your project. This is usually done by keeping all of the code in an online repository. Think of it like using Google Docs for document collaboration.
Repository — A repository contains all of the project files (including documentation), and stores each file’s revision history. Repositories can have multiple collaborators and can be either public or private. They’re easiest to imagine as a project’s folder.
At GitClear, we have leveraged VC in our efforts to help developers increase productivity and code quality while improving communication throughout the company. Some benefits of using version control include preventing changes that have broken your site by allowing a quick roll back to a previous version, and allowing for easier collaboration by keeping code online and accessible to your team.
Here is a brief explanation of VC by the leader of the industry GitHub:
Git — The most widely used version control system, originally developed in 2005 by Linus Torvalds, creator of Linux.
GitHub is the most popular hosting service for git. Using git, GitHub hosts the code for projects online. Anyone with access can add to, remove, or change that code from anywhere. Developers can create copies of this code to their local machine. This copy is called a branch.
Branch — a parallel version of a repository. It is contained within the repository, but does not affect the primary or master branch allowing you to work freely without disrupting the “live” version.
Changes are made to this branch of code and those changed can be merged with the original (master branch).
What does this have to do with developer productivity?
Version control offers insight into when changes were made, why they were made, and what those changes consist of. These are valuable metrics that are essential to the topic of productivity. In VC, a change pushed to the code is a commit.
Commit — an individual change to a file (or set of files). It’s like when you save a file, except with Git, every time you save it creates a unique ID (a.k.a. the “SHA” or “hash”) that allows you to keep record of what changes were made when and by who.
Often developers have widely different commit habits. Some like to write small bits of code and push many small commits to the master branch. This makes changes easier to read, allows a developer to roll back changes in smaller increments, and lets your team identify bugs easier. Other developers like to include many related changes into one large commit. This gives them the opportunity to completely review their code before making any impactful changes.
Since each developer is different in their commit habits, more commits does not equal higher productivity. However, you can look at individual developer habits, and track productivity relative to their own performance. For example, if Frank usually commits 5 times a day, but has committed 7 times each day this week, you can infer something has possibly increased his productivity.
With each commit, developers include a message about why this commit was made. The message should be short and simple, but explain the changes at a glance.
GitClear and other like programs, allow for you to connect your project management software (e.g. JIRA) to your version control system. Each issue, task, or bug can be connected directly to the code that was required to complete the task. Connecting the commits directly to the project being worked on can give a granular view of the actual work that was required to complete each task. Combining this with other metrics will enhance your time and cost estimates. This process is called Issue Mapping.
VC also offers a view into what changes were made in the code. Often large changes are subject to a Pull Request.
Pull Request — proposed changes to a repository submitted by a user and accepted or rejected by a repository’s collaborators. Like issues, pull requests each have their own discussion forum.
GitHub shows the lines that were added and removed. A developer reviews those changes and then either approves them or requests revisions.
Looking at what was changed is where developer productivity gets tricky. More variables start to get added in, such as code language, quality of the code, functionality of the code, and the type of changes made. There’s a lot of information in the data provided, and measuring developer productivity requires interpreting this data and finding correlations.
At GitClear, we use VC to take a deeper look into these changes. Often changes are more involved than just adding and removing code. Often code is moved or replaced. Each action takes a different effort and provides a different value. We give each change a number based on its true impact. By looking at this Line Impact we can better analyze each task and the actual work required.
Line Impact — a relative measure of commit value created by GitClear. Line Impact looks at changes like additions, updates, and removals, and looks at their relative impact together to quantify how meaningful the entire commit was.
In addition to the changes made, each coding language requires varying effort, which lends itself to inconsistency. GitClear allows users to change the multiplier for Line Impact based on the type of code.
Version Control has become an essential variable in software development and the topic of developer productivity. It is helpful not just for the developers but for anyone who needs insight into the work being done.
