Pinpoint Engineering

The TL;DR from my session on AI and EngOps at AIDe...

This morning I had the opportunity to chat with software engineers and data scientists at the AI Dev World Conference on a topic I just happen to be v...

4 real reasons to link your code commits

We all know the best practice: when committing code, link it to the originating issue. This is simple to do, as easy as hashtagging the issue ID in the commit comment. And yet—when you’re under the gun, it’s late, and all that matters is the production push, linking commits is the kind of eat-your-vegetables rule that’s easy to skip.

The case for linking code to issues is straightforward: traceability. It’s better to know than not to know why code was created. It makes impact analysis faster and easier, which in turn contributes to speed, which just about everyone cares about.

Still. All of this feels a little... abstract. In fact, this is the trouble with any number of engineering “best practices.” Too often it’s hard to see specifically how the practice helps me, my team, and/or the company at large. It feels less like an investment, and more like a tax.

(Editorial update: we can now make this link automatically, using machine learning.)

Here’s four ways Pinpoint turns an otherwise academic best practice into actionable data.

One small step, one giant leap

For every commit that’s linked to an issue, we automatically create a ‘steel thread’ that runs from idea to development to deployment. Simply hashtag the issue ID in the commit comment, and Pinpoint does the rest. This means being able to see where development time is being spent, to debug failed deployments and production issues, and to understand where technical debt is accumulating.

Understand the Real Distribution of Work

When it comes to understanding the kinds of work that are consuming people, it’s not what you think is happening or what people say is happening—it’s what’s actually being written. Truth in code.

With traceability, you can see how much of the coding effort is being spent on new features, how much is being spent fixing bugs, and how much is spent doing maintenance—and you can see these splits by person, team, or for the company as a whole.

Linked Commits by Issue Type

Qualifying Technical Debt

By analyzing the connections between code and issues, we can also show you the phase of your different repositories—which are used mostly for maintenance work, versus those used for new features. It also uncovers potential hotspots for technical debt, by showing which files within a repo have a high percentage of bugs, as well as the people and teams whose code tends to produce the most bugs. These data are a starting point to putting real numbers to your technical debt.

Find The Experts

For larger teams, especially those taking on new initiatives, it’d be nice to know at a glance which people in the organization have skills most suited to the work at hand. Refactoring an app? Maybe you want to see who’s squashed the most bugs in JavaScript. Pinpoint uses traceability to show who’s done what kind of work, and in what language(s), making it easy to identify the right pros for the job.

Measure Your Own Contributions

At last: the personal benefit. For lots of us, engineering is an intense, heads-down activity, one where it can be hard to see the forest for the trees. Pinpoint’s analysis of the code-issue connection means a developer can see, e.g., how her code contributed to an improved user experience or better conversion rate.

These insights can also make it easier to quantify otherwise amorphous feelings of frustration about the kind of work you’re asked to do. For example, by being able to show that 70 percent of your coding effort has gone to KTLO-style issues over the last month or quarter, you have an actual, unemotional, data-driven case about being stuck in ‘maintenance mode’. It also becomes possible to see, quantifiably, if/how your work balance changes over time.

Going forward, as we instrument CI/CD systems such as Jenkins and TeamCity, traceability will allow us to show you exactly which issues have made it into production. We’ll have the end-to-end connection, from release, to the actual code in the release, to the issues that code is for. So the next time the business asks, “Did we finally get that feature out?”, you’ll have the answer, right down to the timestamped minute.

Related Post:

Developer Spotlight: Andrew Kunzel, Director of Backend Engineering

Meet Andrew. He’s our Director of Backend Engineering and is a member of Team Bolt ⚡️ who is currently working on buildi...

Developer Spotlight: Michael Goode, Platform Operations Engineer

Meet Mike. He’s a Platform Operations Engineer here a Pinpoint and member of Team Bolt ⚡️ . who is currently working on ...

Developer Spotlight: Matthew Congrove, Head of UI/UX Design

As we ideate around the idea of a Developer Profile, we wanted to learn more about our team and about who they are as a ...

Subscribe to the Pinpoint Engineering Blog

cat developer