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...
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.
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.
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.
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.
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.
CTO and Co-Founder
Meet Andrew. He’s our Director of Backend Engineering and is a member of Team Bolt ⚡️ who is currently working on buildi...
Meet Mike. He’s a Platform Operations Engineer here a Pinpoint and member of Team Bolt ⚡️ . who is currently working on ...