Forem: Nick Hodges

Who Owns Developer Productivity?

Nick Hodges — Tue, 19 Apr 2022 20:35:24 +0000

Developer Productivity has always been a hot topic. For a long time, it was hard to define because it really couldn’t be measured. Lately, thanks to various code hosting platforms providing API access to git repositories, we can start tracking team and even individual performance metrics. (Though I’d strongly recommend against tracking individual developers’ metrics for reason that can be discussed elsewhere …)

So how do you measure how your developers are performing?

Well, it’s actually pretty simple. But it’s not easy. It’s simple because all you have to do is two things:

Get developers to code more efficiently
Get developers to not code more efficiently

There are tons of tools out there that help with the first, but not so many to help with the second. (The second does sound a little weird – basically it’s the notion of improving the process of things that developers do that don’t involve coding...)

Highly productive developers are hard to come by and expensive to train and retain, and so you want to ensure that your team is firing on all cylinders. But how do you do that?

Well, here are a few general ideas I have about how to make developers more productive.

Ensure that they have the best and fastest hardware. If a faster processor on a computer saves a developer five minutes a day, that is 1000 minutes a year, or 16.67 hours. At $100 an hour (probably cheap!) that's $1600 a year. A good machine is easily worth it.
Give them a peaceful environment. The best is individual offices, but if that isn’t possible (and you should try to make it possible in any way you can) then wherever your team ends up, at least have the ethos of being quiet and leaving people alone.
Give developers whatever chair, keyboard, mouse, and other peripherals that they want. Include noise canceling headphones in the list of things you’ll provide.
Engender a culture of excellence. Don’t put up with hacks or sloppy work. Design things and do things the right way every time. Fend off technical debt like a lioness defending her cubs.

Those are just a few of the things that can help improve the productivity of your team. These things are important, and you should do them, whatever your position in your organization.

But perhaps even more importantly, who is responsible for making sure a development team is a finely tuned machine?

It’s that second question that I’m really interested in.

For many years, Google has tackled the issue of Developer Productivity by forming a team focused on what it calls Engineering Productivity. The idea is that if they have a team to focus on making their developers more productive, that team will more than pay for itself in increased value delivered by those developers.

This sounds reasonable – and really great if you are a developer. I love the idea of someone spending their whole day making my life easier.

Historically, only large companies like Google have been able to realize the benefits of a dedicated developer experience team. However, more and more, smaller development teams are seeing the benefits as well, and there has been a rise in popularity of the “Developer Experience Engineer” (DXE).

Obviously if you have a DXE or a DXE team, they will own the process of improving developer productivity, right?

But what if, for whatever reason, you don’t have a Developer Experience entity?

Maybe the Software Development Manager is responsible for developer productivity. After all, they are the ones in charge of getting things done, and they are thus very interested in developers working more efficiently and effectively. If they don’t take an interest in such things, then no one will. Maybe they should be in the business of ensuring that the team has everything they want and need in order to be as effective as possible.

Or maybe the developers themselves are responsible for their own productivity. Maybe a professional developer should make it a point of pride to be as productive as possible, advocating for the tools, environment, and processes that make them do their best work.

Or maybe, just maybe, all these people combine to take on the responsibility. That seems to make the most sense to me. Everyone in the whole software development process is responsible to ensure that the whole team is firing on all cylinders. Developers should be very open about saying what they need to be more productive. Managers should be fighting for budget, process changes, and anything else that developers need to get better work done. DXE engineers should dedicate themselves to finding all the newest and latest software and hardware that will help things move along.

In other words, it takes a team to make the development process more efficient and effective.

The Changing Value of Development Speed

Nick Hodges — Wed, 06 Apr 2022 13:45:03 +0000

An Interesting Poll

I recently asked this question on LinkedIn:

The reason that I asked this question is somewhat interesting.

A Trip to the Past

Back in a previous life, I worked at Borland. For those of you who don’t remember, Borland was at one time a pretty famous software company, competing directly with the Microsoft Languages and Office divisions. Borland is probably most famous for their C++ and Delphi products. In the nineties, they built a beautiful building in Scotts Valley, CA. Their end (as signified where the link above goes) is a story for another day, but suffice it to say that at one point, Borland was on the tips of people's tongues much like Microsoft is today.

Anyhow, Borland had an enormously successful product called JBuilder, the first commercial Java development tool. On the R&D team for JBuilder was a developer – let’s call him Jack – who was notorious for being two things: slow and immensely good. He took a long time to get things done, but his code was, for all intents and purposes, bug-free.

Members of the QA team would try to find bugs in what Jack wrote, but it was very difficult to do. A QA Engineer would consider it a badge of honor to spot a bug in code that Jack wrote.

Sure, he was slow, but as I said, the downstream cost of Jack’s code was very low. Bugs are expensive and time spent fixing bugs is time spent not creating new features. Jack spent a very small amount of time fixing bugs because he didn’t write them in the first place.

Now I give full kudos to Jack’s manager who recognized the immense value of what he could do. It would be very easy for a manager to focus on the “slow” part and not realize the value in the “almost no bugs” part. The total cost of ownership over Jack’s code was actually much lower than his teammates who, while great and faster developers, couldn’t match his level of initial quality.

Back to the Question

Which brings us back to the question I asked.

I asked the question because Jack had recently come to mind in a discussion, and it got me thinking. In today’s development environment, I’m not at all sure that Jack’s unique skill would be as valuable as it once was.

Jack coded in a very different environment than developers today. JBuilder was shipped once a year or so. There were periodic bug fix updates, but new features were generally only delivered annually. The software development process was basically Waterfall – product managers would define requirements, the team would architect and build the features, QA would test, formal beta tests would be run, and the product would ship in one big, grand release.

Now the second half of that equation – all the testing – was pretty time consuming and thus expensive. Having a developer that minimized those costs was very valuable.

But in today’s world, those costs are not as high as they used to be. The advent of CI/CD and a SaaS software solution drastically reduces the cost of a bug.

In the old way, a bug would frequently linger in code for weeks or even months before being discovered. As we all know, the larger the distance between keyboard and bug discovery, the more expensive the fix. The longer the time, the lower the chances that the developer will remember anything about the code she wrote that caused the bug.

But with modern tools like Rollbar, a developer can usually find out about a bug in his code in minutes or even seconds. If a bug is found that fast, the code is still fresh in the developer’s mind, and fixing the bug can be quick and painless. Rollbar can even pinpoint the exact line of code that caused the error.

Fast Feedback and Rapid Response

Now if the feedback loop for a bug is measured in minutes, then I think developers should be encouraged to truly “move fast and not worry about breaking things.” Developers like Jack are still valuable, I suppose, but being slow actually can become a liability. His high-quality code saves a lot of downstream time when you release annually, but when features can be released at any time, and when feedback loops are measured in minutes, a fast developer can often get more done in the same or less time.

For instance, say Jack takes two weeks to develop a feature that our faster developer (let’s call her Sara) can finish in one week. Sure, Jack’s code is flawless, but Sara’s code is pretty good, and she only needs three days to see and fix bugs as the code is tested under a feature flag with beta testers. That means Sara is able to produce what Jack produces with two days to spare.

Changing Development Process

Development processes have changed. Debugging has changed. Tools that monitor and report on errors (think Rollbar!) can make feedback loops much, much faster than those in the world Jack coded it. We now live in a world where bugs have a much lower cost than they had in the past. Given all that, it would seem that Sara is actually more valuable than Jack.

Poll Results

So if that’s true, why the results of the poll? Why don’t people want more Saras and fewer Jacks by almost two to one?

I think there are two reasons. One, many people still aren’t rapid continuous deployment, so the benefits aren’t there for them. And two – teams probably don’t realize the fact that Sara can be more productive than Jack. It is counterintuitive, and not completely obvious until you consider it thoroughly (or just read this article!)

Wrapping up

While productive developers who produce quality code are always a necessity, the actual way that they arrive at that near perfect code changes. Tools and a different mindset about reporting bugs can make “move fast and break things” the order of the day.

Reduce Debugging Time With Rollbar

Nick Hodges — Mon, 14 Mar 2022 13:54:27 +0000

Development time is precious. Developers are highly-skilled and highly-paid, and so naturally you want to make sure that they are as productive as possible. Many organizations are starting to hire Developer Experience Engineers to make sure that their developers are using the best tools and processes possible.

To make developers more productive, the first step is to figure out exactly what developers are actually doing. Then, we need to figure out what we want them to do.

Examining Developer Time

Developers' time can broadly be divided into two areas: Time coding and time not coding. It seems pretty obvious that you want to maximize the amount of time that your developers are coding and reduce the time they are not.

Coding time can actually be broken down further into feature development and maintenance. Feature development – the process of producing new features and value for the customer – is the most desirable thing that a developer can do. Maintenance work – bug fixing – is a bit of a mixed bag. You want your developers to fix bugs, sure, but you don’t want them to have to do it. In other words, bugs are bad and a drag on the team, preventing their coding time from being spent on new feature work.

Non-coding Time

And then there is non-coding time, and it, too, is a mixed bag. Some of it is productive time – code reviews, mentoring, training, creating issues and bug reports, etc. I like to call this meta-coding time. You want meta-coding to happen, but you want it to be as efficient as it can be.

The rest is time well spent – meetings, company events, etc. – but time that you want to minimize as much as is practical. I don’t know a single developer that wouldn’t be pleased with fewer meetings.

So a developer’s time becomes an interesting exercise. You want her coding as much as possible, but on new features and not on bugs, and you want her learning, training, reviewing code, and such – but again, not too much.

So in the end, it seems that you want to maximize new feature time, and minimize non-new feature time (i.e., bug fixing time, meta-coding time, and non-coding time). You don’t want to rush meta-coding time, but you want to do everything you can to minimize it.

Making Developers Productive

Now, much effort has been spent making coding time productive. There are all kinds of tools, IDE features, and other technology to make the process of writing code as efficient as possible. Features like Intellisense have been around for quite a while. Recent innovations such as Copilot from Github are astonishingly useful and productive. (Copilot actually kind of scares me – It is so prescient, like it’s reading my mind…)

Bug-fixing time is especially ripe for improvement. These days, it often involves a lot of investigation such as combing through log files and debugging in an imprecise manner, searching for buried treasure without a map.

Few developers relish maintaining software and fixing bugs. I know some folks who do, but most developers seem to want to write new code and new features. Sure, bug fixing delivers value to the customer, but as discussed above, it’s not time you want to have to spend.

What if there were a way to make bug-fixing more efficient? What if you had a map for your treasure hunt? What if you could be pointed to the exact line of code causing an error?

Would I even ask such questions if I didn’t have an answer?

The Answer

The answer, of course, is Rollbar.

With our AI-driven Error Grouping, we focus on the errors that are most important and impactful, drastically reducing your debugging time by pointing you right to the line of code where the problem is occurring.

Even better, we can notify you of errors immediately, possibly even before your customers see them.

Imagine this scenario:

You have been working on an important new feature. It’s finally ready for beta testing, and so you release it to a select few beta test customers by keeping it behind a feature flag. Those testers use the product, and they find problems. You fix the problems. You test for a significant period of time, and finally you feel confident that all is well, and so you deploy.

However, upon general deployment, a very ugly bug occurs with your customers using the Kanji character set. The problem is that you and your team are sleeping when the error occurs. Customer support starts getting phone calls as customers report the bugs. You count yourself lucky that a customer bothered to report it at all. They aren’t too happy, of course, so you wake everyone up, investigate (which takes a while), realize the severity of the bug, and decide to roll back the deployment, all in the wee hours of the morning.

It takes two days of intense debugging and pouring over log files to see what the issue is, but you fix it and redeploy the new feature successfully. Lots of disruption and grumpy, tired developers, not to mention angry customers that saw the errors.

But if you were a Rollbar customer, things could go more like this:

Everything happens the same, but when the error occurs, Rollbar recognizes it as critical, and automatically rolls back the deployment without waking anyone up at all.

In the morning, your alerts and email let you know what happened. The Rollbar Dashboard shows you the error clearly, including the exact line of code that caused the problem. The correct developer immediately jumps on the issue. It’s soon fixed, and the new feature is redeployed without incident.

No one got woken up, and the feature was redeployed quickly. That’s a win.

Which is the Better Scenario?

I like the second scenario better, don’t you? The customers never see the errors (much less complain about it) since Rollbar backed out the buggy feature before anyone could even know it was there. No middle-of-the-night scrambling. No deep, involved bug hunt, as Rollbar easily pointed the way right to the problem.

Developers want to work on new features. They want to fix bugs that occur, but they don’t want to spend hours searching for the problem.

Rollbar can’t help reduce the number of meetings that a manager calls, but we can reduce the amount of time developers are spending on bug hunting. And less time bug-fixing makes for happier development teams spending more time on things that will deliver value to customers.

Cycle Time Breakdown: Tactics for Reducing Coding Time

Nick Hodges — Fri, 01 Oct 2021 16:00:00 +0000

The Issue: My Coding Time Feels Too High

Cycle Time is the Dev Manager’s Super Metric. So naturally, the conscientious Dev Manager will want to pay close attention to Coding Time, the very first segment of a project’s journey along the Cycle Time path. Keeping Cycle Time “all green” is the goal, but this is often difficult because there are a lot of moving parts that go into managing Cycle Time. One of those moving parts that are hard to keep in control of is Coding Time.

Coding Time is defined as the time between the first commit made to a branch to when a pull request is submitted. As a general rule, you want your coding time to be two to three days. Anything above four days is considered worrisome, and a Coding Time above seven days is a real problem. Many elite teams are able to measure Coding Time in hours, not days.

In the past, we could measure the notion of Coding Time only anecdotally. Perhaps you could keep track of how the coding on a project was going by the reports in a daily standup.

However, these days, managers are demanding more — they want hard data. LinearB provides an overview of Cycle Time for all your projects on the main dashboard that includes a clear indication of the status of your coding time. This dashboard is data-driven, based on the work committed to your code repository.

Here you can see that coding time is turning orange- meaning that it is getting worrisome and should be looked at more closely. At this point, things are heading in a sub-optimal direction, but the dashboard shows this fact to you in real-time. You are able to quickly see any bottlenecks almost immediately just as they begin to be a problem.

What’s the cause?

There are three main reasons why a branch might have high coding time:

The project is too large
The project is too difficult
The project is languishing

The Project is Too Large

This is probably the most common reason that Coding Time expands beyond desired boundaries. The branch the project is based on will often have many commits. The “chunk” of work is too big to complete in the standard set for normal coding time. In general, the Coding Time is longer because there is simply too much work and not enough time.

The Project is Too Difficult

Sometimes, your project might be broken down into appropriately sized chunks of work, but it turns out that a given chunk of work is harder than anticipated.

Maybe the problem wasn’t completely understood, and the effort required to do the task was greater than originally thought. Or perhaps there were a number of “unknown unknowns” that were discovered, making the project bigger than anticipated. Another indication of this problem is high levels of code rework and refactoring.

The bottom line here is that things were more difficult than anticipated.

The Project is Languishing

This one is pretty simple: The Coding Time is taking longer than expected because the project was started, but left alone unworked. Most likely the developer was required to turn to other tasks based on new priorities, and the branch was left unaltered for a long period of time.

Investigating High Coding Time

The first thing to do about growing Coding Time is to find out which projects or branches are the ones causing the problem. In order to do that, you can drill down into the LinearB dashboard and take a look.

To look more deeply, you can click on the little arrow in the upper right corner of the Cycle Time Box.

Doing that will take you to the Branch View of your repository. From there, you can see all the branches that are affecting your coding time.

For instance, the top branch below had a coding time of almost eight days — a length of time that contributed to the Coding Time for the team being higher.

Note, too, that you can see the exact contribution that any branch is making to the overall Cycle Time by simply hovering your mouse over the Cycle Time column of the given branch. Thus you can quickly see which branches are causing problems for your Coding Time.

For example, by analyzing our own coding time data over the past fifteen months, we’ve found that fewer than 20% of Pull Requests make up the majority of coding time issues. Oftentimes these are Pull Requests that were forgotten about due to a high level of context switching or where the chunk of work was too large.

Once you determine where the long coding times are, you’ll want to know why those branches are causing a problem. That is — which of the three reasons above do the problematic branches represent.

Once a branch has been determined to have a Coding Time problem, you can click on the name of the entry and be taken directly to the git page for that branch, where you can determine what the issue is, whether it be too much work, code churn, or the branch simply isn’t being worked on.

From there, you can work with your team to correct the issues going forward and get your Coding Time back into the green.

Preventing High Coding Time

Naturally, what you really want as a manager is to prevent Coding Time from being a problem in the first place.

If you are not already using LinearB and want to do things like track Cycle Time and Pull Request Size, sign up for a free demo of the product today!

The first thing you can do towards that goal is to educate your team on the need for dividing your work into small, manageable chunks. Pull requests that are too large are a clear indication that the chunks of work are too big. Big Pull Requests will also tend to make PR Review Time longer as well.

Pro Tip: High-performance engineering teams try to break their work into less than 150 code changes per Pull Request.

You could check the Branches page each week, looking for large Pull Requests that indicate long Coding Times.

You might then even bring this metric into your sprint retrospectives. If your team agrees that improving Pull Request size is important, you can set it as a goal for your next sprint and celebrate a win during the retrospective.

Second, in order to warn your team about large chunks of work, you can configure the Work at Risk notifications to notify you of branches that are heading in a bad direction so you can take corrective action before they become real problems.

To allow you to keep a close eye on Coding Time, you can create a custom dashboard with PR Size and Coding Time on it so that you can easily check on these important values at any time.

Finally, you might check the Daily Digest notification message for branches that have more than 100 code changes, stuck work, and pull requests with more than 6 comments. These are the branches that are very likely problematic and worth investigating before they cause Coding Time to rise.

The End Result

Keeping Coding Time, and thus Cycle Time, under control is a critical means to continuously improving your software development process. By monitoring Pull Request size, keeping an eye on individual branches where Coding Time is pressing up against your limits, and by warning you and your team about Work at Risk, you can ensure that your Coding Time stays under control.

But more importantly, LinearB can help you ensure it doesn’t happen in the first place. Our tool lets you recognize that there is a problem, dig in to find where the problem originates, and take the necessary steps to correct things. If you are not already using LinearB and want to do things like track Cycle Time and Pull Request Size, sign up for a free demo of the product today!

Originally published at https://linearb.io on July 16, 2021.

Cycle Time Breakdown: Reducing PR Review Time

Nick Hodges — Thu, 30 Sep 2021 22:59:06 +0000

The Issue

As a manager of a software development team, you are always under pressure to deliver value to the customer. In order to do that more effectively, you monitor your Cycle Time and work to keep it as low as possible so that features get into production as quickly as possible.

One of the issues that can be a bump in the road towards meeting that goal is Review Time. Review Time is defined as the time between the first comment on your code and the time it is merged back into the main branch. It’s the third phase of Cycle Time and keeping it inside proper boundaries is critical to keeping quality code moving through the pipeline.

Review Time is interesting because you don’t always want to make it shorter like Coding Time and Pull Request Review Time.

A good development team wants a solid review, one that is neither too short nor too long. A quality team will try to keep Review Time between one and two days. A Review Time much less than 24 hours likely indicates that an insufficient review has been conducted. A too-long review can mean a number of things, including the Pull Request is too large, the review is complex, or the review has been ignored.

LinearB provides an overview of Cycle Time for all your projects on the main dashboard that includes a clear indication of your Review Time status. This data-driven dashboard is based on the work committed to your code repository.

So how does this happen and what can you do about it?

Causes of High Review Time

Out of range Review Time can happen for a number of reasons

The team has too much Work in Progress (WIP)
The team has been distracted or pulled away by other work
Too few people are assigned to do reviews
The review has been forgotten

Too much WIP

If the team has too much work to do, they may tend to ignore Code Reviews in order to press forward with their overstretched schedule. This will lead to reviews taking longer than wanted, or for reviews to be superficial or ignored altogether.

The team is distracted by other work

Sometimes a senior leader or executive asks a developer for special work or to fix a specific bug, drawing them away from their regular work, causing Review Times to extend.

Too few people are assigned to do reviews

Some teams limit the number of people who can do Code Reviews, and this can cause a backup in getting them done.

We at LinearB recommend that everyone be encouraged to participate in Code Reviews. Obviously, the wisdom and knowledge of senior developers can help ensure that code is correct, but junior developers can also spot problems as well as learn from the process.

The review has been forgotten

Sometimes, just by error or happenstance, a review can be forgotten. Tracking Pull Requests through the review process is a manual process, with managers having to be alert for errant reviews. However, features like LinearB’s WorkerB can be used to automated team alerts and personal notifications for Slack and MS Teams in order to notify developers when a review has been forgotten for a configurable period.

How to Decrease Pull Request Review Times

Without a metrics tool, tracking Review Time and keeping code moving through the development pipeline can be a real bother. Reviews need to be tracked manually, emails need to be sent, and developers are bothered by flow-breaking communications.

This is where LinearB comes in — it can show you the information you need to see bottlenecks and automate almost everything involved with keeping Code Reviews moving. You can set up a custom dashboard explicitly for the purpose of tracking Pull Requests and Code Reviews.

Even better, you can set up WorkerB to immediately notify your team members about Pull Request events, helping them react more quickly to Code Reviews and drastically reducing Review Time.

If you are finding that your reviews are frequently too long, you can take these steps to shorten them:

Ensure that your Pull Request Size isn’t too big
Don’t allow reviews to languish
Ensure that completed reviews are merged right away
Reduce the team’s workload

Ensure that your Pull Request Size isn’t too big

Large Pull Requests make for difficult, and thus often long, code reviews. If a Pull request is large, developers will be hesitant to jump in and contribute. When they do, the size of the review may cause the review to take longer than desired. Our experience with customers at LinearB is that any Pull Request with over 200 changes will result in hesitancy by developers to do the code review.

Don’t allow reviews to languish

Sometimes a developer will pick up a review, but not act on it, possibly forgetting about the review altogether. WorkerB can warn about this via the Long Review notification.

Ensure that completed reviews are merged right away

A long review can occur if the review has actually been completed, but not merged back into the main branch.

Again, both WorkerB and the Pulse view can warn you about long reviews. Pulse is a view that shows you real-time updates for all your features in a single view by synchronizing your git branches and Pull Requests with your project management tool.

Reduce the team’s workload

Often a review will take longer because the team has a lot of Work in Progress (WIP) and thus developers feel they don’t have time to do code reviews. Perhaps the review gets started but never finished because team members are feeling the time crunch of too much WIP.

You can configure on a team-by-team basis how many tickets are considered too much WIP.

What to do when review times are too short

Monitor Review Depth

A factor in reviews that are too short is the notion of Review Depth. A too shallow review indicates that you either have a single contributor that only knows the code and that no one else understands the code, and the Pull Request simply gets approved without comment or too few comments.

Monitoring Review Depth can give you insight into why Review Time may be outside specifications. You can set up a WorkerB Team Alert to quickly notify everyone when a review is merged with the number of review comments below a level that you can determine.

Monitor PRs Merged with Basic Review

Another metric that can help reveal why reviews are too short is Pull Request Merged with Basic Review.

You can set up a WorkerB Team alert for this as well, ensuring that you are notified if a potentially insufficient review was merged.

The End Result

Keeping your Review Time “just right”, and thus keeping Cycle Time under control, is a critical means to continuously improving your software development process. By monitoring Review Time and ensuring it is within desired limits, you can see your Cycle Time drop like a rock.

One of our customers, Unbabel, an artificial intelligence-powered human translation platform, saw a 40% decrease in Review Time when following these principles while using LinearB. Reduced Review Time means reduced Cycle Time, which means more value delivered to the customer sooner.

By ensuring timely Code Reviews and the proper processing of Pull Requests, you can create an environment where Cycle Time is low and value is delivered to customers in a timely manner. Tools like WorkerB can ensure that your team is informed about problems with respect to Review Time and take action accordingly.

LinearB can make such an environment happen, and happen fast. Our tool lets you recognize that there is a problem, dig in to find where the problem originates, and take the necessary steps to correct things. If you are not already using LinearB and want to do things like drastically reduce your Cycle Time and Review Time, sign up for a free demo of the product today!

Originally published at https://linearb.io on August 4, 2021.

Cycle Time Breakdown: Reducing Pull Request Pickup Time

Nick Hodges — Thu, 30 Sep 2021 15:20:15 +0000

The Issue

There’s nothing worse than working hard for a day or two on a difficult piece of code, creating a pull request for it, and having no one pay attention or even notice. It’s especially frustrating if you specifically assign the Pull Request to a teammate. It’s a bother to have to remember to send emails or slack messages to fellow team members to get them to do a review. No one wants to be a distraction, but the work has to be done, right?

So naturally, the conscientious Dev Manager will want to pay close attention to Pull Request Pickup Time (PR Pickup Time), the second segment of a project’s journey along the Cycle Time path. (Go here for the blog post about the first segment, Coding Time) She’ll want to make sure those frustrations described above don’t occur. Keeping Cycle Time “all green” is the goal, but this is often difficult because there are a lot of moving parts that go into managing Cycle Time, including PR Pickup Time.

PR Pickup Time is defined as the time it takes from when a pull request is issued until a review has started. Ideally, PR Pickup Time would be measured in minutes. Anything over a day should be considered worrisome.

However, these days, managers are demanding more — they want hard data. LinearB provides an overview of Cycle Time for all your projects on the main dashboard that includes a clear indication of the status of your PR Pickup Time. This dashboard is data-driven, based on the work committed to your code repository.

In this graphic, you can see that pickup time is red. That is, you can quickly and easily visually identify workflow bottlenecks using LinearB’s Cycle Time breakdown.

So how does this happen and what can you do about it?

What's the cause of slow PR Pickup Times?

There are three reasons why your repository will have a high PR Pickup Time:

The team doesn’t know the PR exists
The team is too busy
The Pull Request is too large

The team doesn’t know the PR exists

It may be as simple as the team doesn’t know that a Pull Request is waiting to be picked up. Perhaps the developer failed to assign the Pull Request to anyone. If the process is for the requesting developer to send out an email to the team announcing the Pull Request, and he forgets, then it is much less likely that anyone will know the Pull Request exists.

The team is too busy

Teams and developers that have high Work in Progress (WIP) are less likely to quickly pick up a Pull Request. They may feel pressure to get their current task completed, and don’t feel free to stop work and perform a code review. They may figure that someone else will come along and pick it up.

The Pull Request is too large

A large pull request can be daunting, and many developers may hesitate to take on a large code review, perhaps hoping another developer will jump in and take on the task. Our experience with customers at LinearB is that any Pull Request with over 200 changes will result in hesitancy by developers to do the code review.

Investigating High PR Pickup Time

Tracking PR Pickup Time is very straightforward in LinearB.

First, you can easily see a list of Review Requests Hanging on your LinearB Dashboard.

Simply click on the drill-down arrow in the upper right corner of the Dashboard, select the Pull Request tab, and click on “Review Request Hanging” and set your search criteria as desired.

This listing will include all Pull Requests that haven’t been picked up after a configurable amount of time.

Second, you can monitor PR Pickup Time trends in a metric in a Custom Dashboard.

This metric can tell you how your team is performing over time with regard to pickup time. Obviously, you want this metric to be as low as possible. Here you can see that PR Pickup Time was good until the “Suns” iteration when the pickup time jumped to a sub-optimal level.

5 Tactics for Reducing High PR Pickup Time

Naturally, once you realize that your PR Pickup Time is climbing, you’ll want to do something about it. LinearB gives you a number of ways to track things and take action with your team.

Ensure Work In Progress (WIP) isn’t too high

As mentioned above, busy teams often tend to avoid picking up Pull Requests, wanting instead to finish their work — work that is too much to allow for code reviews.

You can monitor the level of WIP that developers have via the Pulse View. The Pulse View is available in the menu on the upper right of LinearB’s header.

Here you can see that the selected developer Ashley is currently working on four separate projects, indicated by the four rows in the view. This number of projects is often too many. He will be less likely to want to pick up a Pull Request as a result.

It’s best to keep WIP at a level that allows developers time to do code reviews.

Keep PR Size as small as possible

Keeping the size of your Pull Requests as small as possible has many benefits, including making it more likely that a developer will take on the task of reviewing the code in the pull request.

In working with our customers, we’ve found that the very best teams keep their Pull Request Size below 150 changes. Low Pull Request Size results in lower Coding Time, better Review Time, and yes, better PR Pickup Time.

Use Real-Time Automation to keep Pull Request moving

WorkerB is designed to give notifications when events happen (or sometimes don’t happen) in your code repository.

For example, WorkerB will notify a developer when she has been assigned a Pull Request. This makes it much more likely that she will actually pick it up.

WorkerB will also notify the development team when a Pull Request has not been picked up for a configurable period of time.

LinearB customers see a drastic reduction in Cycle Time when using WorkerB, averaging a 50% decrease.

You can learn more about connecting up WorkerB in our documentation.

If you are not already using LinearB and want to do things like track Cycle Time and Pull Request Size, sign up for a free demo of the product today!

Configure a Custom Dashboard to start tracking Pickup Time

LinearB provides many different metrics that you can use to monitor what is happening inside your development environment. You can even create custom dashboards that enable you to see specific insights. For example, you could set up a custom dashboard to monitor the status of your pull requests, ensuring that they are processed in a timely manner.

The Pull Request process is the heart of your software development life cycle. By optimizing it, you can see drastic reductions in Cycle Time, which means more value being delivered to your customers faster. Pull Requests should be picked up quickly, reviewed in a complete and timely manner, and then merged promptly.

Above is a dashboard that tracks Pickup Time as well as Review Time, Review Depth, and Pull Requests merged without a review. In one glance, you can get a notion about the health of your whole Pull Request process.

The End Result

Keeping PR Pickup Time, and thus Cycle Time, under control is a critical means to continuously improving your software development process. By monitoring Pull Request size, engaging WorkerB, and monitoring Work in Progress, you can see your Cycle Time drop like a rock.

Imagine a world where you simply monitor the progress of your Pull Requests and in less than one quarter, you see your PR Pickup Time and other Pull Request metrics drastically improve merely by doing that monitoring. Say you are able to decrease your PR Pickup Time from three days to four hours. That alone is a 68-hour — almost the whole three days! — reduction in overall Cycle Time. Your boss will be impressed.

LinearB can make such a world happen, and happen fast. Our tool lets you recognize that there is a problem, dig in to find where the problem originates, and take the necessary steps to correct things. If you are not already using LinearB and want to do things like drastically reduct your Cycle Time and Pull Request Size, sign up for a free demo of the product today!

Originally published at https://linearb.io on July 23, 2021.

Customize Your Engineering Metrics Dashboards in LinearB

Nick Hodges — Wed, 29 Sep 2021 22:47:21 +0000

Introducing Custom Engineering Metrics Dashboards 🚀

I’ve been a Software Development Manager without the right metrics. Believe me, it’s a challenge.

But you don’t have to be like I was anymore. Now you can not only have metrics to give you insight into what your development team is doing, but you can view those metrics in exactly the way that you want to see them.

LinearB’s new custom dashboard feature allows you to build a metrics view that makes the most sense for you and your team.

You might need a specific set of metrics for a specific meeting or as the first thing you look at every morning.
Maybe you have some specific concerns about your team and want to track some metrics that will help you deal with those concerns.
Maybe you want to keep track of everything happening with the pull requests on your team.

Whatever it is, LinearB’s Custom Engineering Dashboards can give you the view you want when you need it.

Our custom dashboards are even customizable! We went above and beyond with this feature by allowing your custom dashboard to be set as a private or public, any number of colors, line or bar graph. You get to choose.

You can even show it off to your boss or embed a view in PowerPoint by simply exporting the dashboard as a PNG file.

Create your custom dashboard in less than 60 seconds

Here’s a video of me creating one in about a minute. Seriously — it’s that easy

This Release Note has step-by-step instructions if you prefer to read how to do it.

Useful Dashboard Examples

DORA Metrics Custom Dashboard

The DORA Metrics are all the rage these days. Many software development leaders are using them as a baseline for keeping track of their development teams.

Here is a dashboard that displays three key DORA Metrics:

With this dashboard, you can see that Cycle Time has been climbing recently. You might wonder why deployment frequency is dipping, and you can see where the team likely struggled with fixing the application.

With this simple view, you can see at a glance how your team is performing and what mid-course corrections you might need to make.

Tracking Pull Requests with a Custom Dashboard

Pull Requests have become more common in recent years. They have tons of advantages, and add huge value to the process of committing and merging code into your codebase.

But there can be some landmines with Pull Requests. They can be too big. Sometimes they can languish waiting to get reviewed. Or they might get only a cursory review. I would have loved to be able to track all these things at a statistical, precise level rather than guessing about things as they happened. I would have loved to have this dashboard, for instance:

Now, that’s a lot of data, but if after looking that dashboard over, you don’t have a complete view of what is happening with Pull Requests in your code base, well, I don’t know what to tell you. 😃 Maybe you don’t want all those metrics because it is too much, but that is the beauty of custom dashboards. You can tailor it to whatever you want.

A Custom Dashboard for Your Daily Standup

When I was a Development Manager, I struggled to make my daily standups useful, interesting, and purposeful. The meetings would often be each developer kind of droning on about what he was doing, etc. The meetings were boring, and frankly, I began to wonder if they shouldn’t be completely made over.

What I really could have used were some key metrics to make my development team stand up more useful and effective.

Here’s a dashboard that would have been very useful to review every day in my team standup:

This would be perfect to review before you go into the standup, or even go over it with the team in the standup.

Along the top, I can see three very important metrics about the team’s Pull Requests: the size of pull requests (you don’t want them too big), the amount of review pull requests get (you don’t want it too small), and the amount of time it takes to do a review (you want it just right).

On the bottom, I can see how many code changes my team is making, how much time each project is spent in coding, and how much of the code they are writing is new code.

Now you may want to track different metrics, or have those metrics that you do track alter over time. That’s fine — you can easily update your dashboards at any time.

Show Us Your Custom Engineering Metrics Dashboard🎉

So go give it a try. As seen in the video above, creating your own new custom dashboards is startlingly easy.

We’d love to see your own custom dashboards

If you are an existing customer, you can already use this feature.

If you aren’t yet a customer, you can sign up for free with just a few mouse clicks.

Once you are rolling, here’s what you can do:

If you aren’t a member of our Discord Community, it’s totally anonymous if you want and very easy to join.
Create your own dashboard.
Export it using the Export to PNG Feature. (See the “Share” button in the upper right)
Go to our #show-off channel and post your dashboard along with a description of why you chose the metrics that you did.

Post your dashboard and its description, and we’ll send you a free Dev Interrupted t-shirt!

Originally published at https://linearb.io on May 7, 2021.

WorkerB Developer Automation From LinearB

Nick Hodges — Wed, 29 Sep 2021 15:54:23 +0000

“The most powerful tool we have as developers is automation.”
—Scott Hanselman

Developers automate everything about how we write, test and ship code. But when it comes to the process of how we work together as a team on projects, it’s highly manual.

I have to manually update Jira. I have to remember which of my PRs need attention and manually send a Slack message to my teammate asking for help. It takes dozens of clicks to see my open PRs in GitHub. I have to manually update my manager when I finish a piece of work or start on a new ticket. GitHub has a detailed record of everything I’m doing so why do I need to manually keep track of everything and physically input all of my updates into a project management system?

Introducing WorkerB Developer Automation

To help developers save time, eliminate annoying manual tasks, reduce tab and context switching, and remove project idle time, we built three types of automation:

Personal automation
Team automation
Project automation

Personal Automation

Type /lb help into Slack (MS Teams coming soon!) and you’ll see a list of useful commands to help you see all of your PRs and reviews together, without clicking around.

If you don’t have a LinearB account, click here to sign up free. If you have not linked Slack to LinearB, click here to connect your account.

One command I use every day is **/lb reviews. **It shows PRs currently assigned to me and with one click I can get to them directly in GitHub / GitLab / Bitbucket (Azure DevOps coming soon!)

You can also configure alerts to notify you proactively of events on your PRs.

I really like the “PR request changes” alert. It saves me from leaving my IDE every hour to see what’s happening with my PRs.

Team Automation

Your team can configure policies based on your specific way of working to cut idle time and establish PR review quality guardrails.

When a policy triggers, LinearB alerts the team Slack channel of your choosing (MS Teams coming soon!) and provides links to the related branch or PR. Since LinearB correlates your Git work with your projects stories, we show you the related story so you can prioritize your follow-up accordingly.

The “Long review” alert has been really helpful for our team since we moved to work-from-home. We get alerted when a review has been open for longer than 2 days. Other teams at LinearB have it set to trigger after 3 days.

Learn more about configuring your team policies in this help article.

Project Automation

The LinearB Pulse board shows a live timeline of Git activity correlated to each of your projects / features / bugs. It makes our daily stand-up more efficient by summarizing blockers, WIP and open tasks for every developer on the team.

Pulse detects when your real-life work in Git does not match the status of your project management system and allows you to update the status with two clicks, without logging into your project system.

In the example below from our Pulse board today, the story add share button to custom dashboard *was marked *Selected for Sprint in Jira when in reality it was *In Progress. *We know it’s in progress because the little blue dots on the Git Activity Timeline on the right indicate multiple commits. We noticed the discrepancy during the meeting and fixed it in real-time.

More Automation Coming Soon ⌚

We’re busy building more personal, team and project automations to help you save more time:

Branch-to-ticket matching: We’ll notify you when your branch or PR is not linked to a ticket and help you match it with an existing ticket or create a new ticket (without going to your project tool).

PR auto-close: When you receive a LinearB alert that your PR has been approved, you can also close it with a single click.

Idle ticket alert: We’ll detect when an important feature or bug has been idle, based on your Git activity, and alert you based on your team’s policy configuration.

Summary

Developers like workflow automation because it saves us time, cuts down on tab and context switching, helps us be more responsive to teammates and helps us get through reviews faster so we can merge and move on to the next thing.

Team leads like workflow automation because information travels faster which reduces idle time and speeds up development cycle time.

If you have a LinearB account, you can use all of these automation features now. If you don’t have a LinearB account, click here to sign up free. If you have not linked Slack to your LinearB account, click here to connect your account.

Originally published at https://linearb.io on May 4, 2021.

Find Unplanned Work And Match Developer Effort To The Right Project With LinearB Matchmaker

Nick Hodges — Tue, 28 Sep 2021 15:58:20 +0000

Even the best developers sometimes find themselves investing time into unplanned work that is not aligned to current team priorities.

The CEO asks for something urgent.
A shiny new object becomes a distraction.
There’s a misunderstanding about priorities.

Sometimes devs are working on the right priority but it looks to teammates and leaders like they’re not:

Branches/PRs are not linked to the project ticket.
Project tickets status is not up-to-date.

Unplanned work is the #1 cause of missed deadlines and miscommunications between engineering and business. But not all unplanned work is bad!

Does this story sound familiar? 👇

Developer starts working on a new feature. The new feature relies on an old part of the code base with ugly technical debt. Developer decides to fix tech debt because A) it will make the product better overall, B) it will make building the feature easier and faster and C) it will help the new feature work better for customers.

Unplanned work is the #1 cause of missed deadlines and miscommunications. We built Matchmaker to deal with that.
Get it now. Free for dev teams

This is a win, win, win, right? Yes, at LinearB we encourage our developers to exercise this judgement. Except on some teams this decision could create confusion because the work is unplanned and undocumented. If we rely on individuals to manually communicate these changes verbally or in our ticketing system (🤣🤣🤣), we may not find out about them until it’s too late, if at all.

To empower every developer to be a decision maker and ensure all work is correctly attributed to the right project, we built Matchmaker.

Matchmaker starts in LinearB Pulse. Since Pulse correlates your Git activity to your project stories in real-time, it knows when you’re writing code in a branch that is not connected to a project story.

But here, we are interested in the text in the upper right where you are told how many branches are unlinked to project work:

Here, we see that the code base has a total of six branches that aren’t linked to work tickets. If you click on the text, you get taken down lower on the page to look at the specifics about these unlinked branches:

Here you can see the unlinked branches. You can see the branch names, who is working in them, and what the level of effort is on each one.

In one of the branches, highlighted above, we have some code that isn’t linked to a work ticket. The small purple dot indicates that the work was done mid-sprint, but wasn’t reviewed and merged. Not only that, but it’s been waiting a while for that review. If you are a manager, you probably need to look into that and find out what is going on.

If you are a developer, you want to know that what your working on isn’t being properly tracked.

This particular branch is refactoring work — effort that is valuable and needed but that doesn’t tie back to a specific project task.

Coming Soon!

We aren’t standing pat. Matchmaker is improving in the near future.

Coming soon, we’ll be integrating this feature with Slack Alerts. If a developer creates or commits to a branch that isn’t associated with an issue, a personal alert will be sent to that developer on Slack, immediately making them aware.

In addition, we’ll make it even easier to take action on that alert by allowing you to connect an unmatched branch to the correct project tool ticket, right in Slack.

Benefits

So, this feature lets you see what is happening and correct it if need be. You can see the extra work that developers are doing outside of the “official” work that they are supposed to be doing. Maybe the work is okay and you can make it official. Maybe it’s not and you need to redirect the developer back to the proper tasks.

There are benefits for the developers as well — perhaps a developer created the branch and didn’t properly name it. She can see that and correct it. She can get noticed for refactoring and reworking code.

Either way, Matchmaker solves a number of problems for you. Shadow Work can derail your project. Being able to see it allows you to do something about it. You can peer into your code base in a new way to ensure that the work that is being done is work that should be getting gone.

How does it work?

Matchmaker is triggered when a branch name doesn’t match your team’s naming convention. Here at LinearB we name our branches with our project tool’s ticket number, like so:

PROJ-3435-some-new-feature

We then include the ticket number “ PROJ-3435 “ in our branch name and LinearB sees that and knows that a properly named branch is associated with that ticket.

It also knows that a Pull Request is associated with a ticket in the same way.

Branches that are worked on that don’t match the naming convention are highlighted by Matchmaker.

Conclusion

Matchmaker is new and powerful. It will save you time and keep things in order by:

Finding code not attached to a project story
Visualizing the size and scope of activity
Helping you match the work to the right project
Alerting the developer privately in Slack (Coming Soon!)
Matching the branch to the right story with one click (Coming Soon!)

Give it a try today!

Originally published at https://linearb.io on April 16, 2021.

Brain Time vs. Butt Time: Improve Developer Productivity

Nick Hodges — Fri, 27 Aug 2021 15:57:13 +0000

Many moons ago, I tweeted the following about how to improve developer productivity:

Tracking Time

There is a pretty big controversy in the software development community about logging time. Of course, if you are billable, you need to log your time, but what if you aren’t? Should you have to keep track of the time you spend writing code? Does tracking time do anything to improve developer productivity?

Now I know that no one really likes to track their time. It’s a pain. It’s challenging to be accurate. It’s hard to get time properly categorized. But it can be invaluable for making those important business decisions. I’m not going to solve that argument here.

But there is a bigger problem with measuring time. The only thing you can really measure is “Butt Time”. Butt Time is the actual amount of time someone has their butt in a chair while working on a project.

You need Butt Time to get any work done, of course. But managers should not be insisting on a lot of Butt Time. Butt Time isn’t really what you want to maximize. What you really want to foster is Brain Time.

What Do You Really Want to Measure?

Butt Time isn’t at all equivalent to productive development time. Butt Time includes reading email, answering questions and generally handling any number of interruptions, daydreaming, personal calls, meetings, and other distractions. And those distractions, however minor, break a developer’s concentration. It is also time spent not working on the task at hand.

When you get right down to it, development is all about concentration — Brain Time. With a coding project of any size at all, doing development requires complete focus and attention. You need to build up complex data structures and patterns in your mind in order to really be productive.

Doing this takes time — I’ve heard it described as building a house of cards in your mind. Building that house of cards can take upwards of fifteen minutes depending upon the project. But here’s the bummer: It only takes a second for that house of cards to come tumbling down. One distraction can make your fifteen minute investment disappear.

The Zone

And of course, time spent in “The Zone” — with that house of cards constructed and true, highly productive work getting done — is what we all are seeking. We’ve all probably had that awesome experience of getting into that zone for hours at a time and wondering where the time went. We know how cool that is — and how precious. That’s what we want to measure — Brain Time.

But that’s a really hard — if not impossible — thing to do. Getting accurate, meaningful Butt Time measurements is difficult enough. But how in the world can you actually measure Brain Time?

I’ll argue that you really can’t. In the end, Butt Time is only a poor proxy for Brain Time. And all too often, managers will use Butt Time as a measure of productivity. What we need to do is to try to increase the Butt Time to Brain Time ratio by providing an environment where Brain Time is maximized as a percentage of total Butt Time. It’s critical to improve developer productivity.

What Can You Do to Improve Developer Productivity?

There are ways to do that — ensuring that your developers have an office with a door that they can close is an important first step. The book Peopleware is really the Bible for this, and Joel Spolsky has talked a lot about it as well. Uninterrupted quiet time is the key. Leaving developers alone is critical to maximizing Brain Time.

Developers inherently know that “Butt Time” isn’t really important. They know that time spent thinking is way more valuable. I’ve known developers that do some of their best thinking while wandering the halls, allegedly “doing nothing” (Heaven forbid that a developer isn’t sitting in their chair!), or making a cup of coffee.

Managers should make sure that they aren’t expecting developers to be sitting and typing all the time. Sometimes great work gets done while simply staring at the screen doing nothing. Sometimes walking the dog brings about an epiphany.

Join in on the discussion about all things Software Development on the Dev Interrupted Discord Server!

Managers should recognize this and encourage their team to do what they need to do to do their best thinking. If a developer can concentrate at night from 10:00pm to 3:00am, then she should be encouraged to work then. Every developer is different, and a good manager will learn what works for their team members and provide for that.

Another thing we need to do is to respect — indeed, celebrate — those developers that are quiet and don’t say much. Many developers are introverts that don’t say much at all. They come to work, write great code, and go home. But sadly, we don’t always respect this. Being quiet is a very valuable virtue in a software developer — both because they themselves are being productive and they aren’t breaking other’s concentration. We should give honor and respect to that.

Butt Time is easy to come by and fairly easy to measure. Brain Time, however, is a precious and hard to measure commodity that needs to be nurtured and respected. If you really want to improve developer productivity, optimize for Brain Time.

If you haven't already heard, Dev Interrupted is hosting INTERACT: The interactive, community-driven, digital conference that takes place September 30th. Designed by engineering leaders, for engineering leaders, INTERACT will feature 10 speakers, 100s of engineers and engineering leaders, and is totally free.

Register Now

If you haven’t already joined the best developer discord out there, WYD?

Look, I know we talk about it a lot but we love our developer discord community. With over 1500 members, the Dev Interrupted Discord Community is the best place for Engineering Leaders to engage in daily conversation. No salespeople allowed. Join the community >>

Originally published at https://linearb.io on April 23, 2021.

Engineering Metrics: 3 Levels of Visibility

Nick Hodges — Thu, 26 Aug 2021 15:08:35 +0000

Introduction

LinearB has all sorts of engineering metrics for your software development pipeline. We can slice and dice those metrics from all kinds of angles and all sorts of ways. Your CTO will want to see very different views of LinearB data than will your developer leads. Whether you are trying to see into the health of your delivery pipeline, seeking out bottlenecks in your system, or worried about making sure only LinearB can help you gain those insights.

Since the presentation of data is critical to its effectiveness, LinearB allows you to create views into your data for different levels of your organization and your code. The three most interesting views into your data are:

Organization Level Engineering Metrics
Team Level Engineering Metrics
Repository Level Engineering Metrics

Organization Level Engineering Metrics

The highest level view of your company’s engineering metrics is at the organizational level. This is the view that rolls up everything that every developer on all your teams does into one single view.

An organization-level view helps you align business priorities by visualizing your project investment at the 50,000-foot view. As an executive, you plot the course and fly the airliner. You need to make sure your team’s efforts are aligned with business goals and that you are doing everything in your power to ensure the success of crucial projects. By viewing things from the top, you will be able to get the proper glimpse into what and how your development team is doing.

Why look at the organization-level engineering metrics?

The organization-level engineering metrics view is usually most valuable for the CTO or VP of Software Engineering. It provides a complete, high-level look at everything happening in the software development realm. CTOs and VPs can get an executive summary of things like Cycle Time, Work Breakdown, and your Investment Profile.

They can get a high-level view answers questions like:

What is the team working on?
How fast are we delivering that value?
Where is our investment going?
What do my DORA metrics look like?

Let’s take a look at how LinearB can answer these questions.

What is the team working on?

The Project View can show you exactly what projects your team is working on and the high-level status of each of those projects:

How fast are we delivering value?

Organization-level Cycle Time can tell you how well the team is delivering value. A lower cycle time means more value is arriving in the customer’s hands sooner. It also means that you are breaking your work into smaller, more manageable chunks, thus encouraging good Code Review practices. For instance, if you identify that your Coding Time is a problem (as below) then you can take action to correct it.

Where is our investment going?

You can see what the team is working on via the Investment Profile View. This view tells you the type of work and what percentage of each type is being done by the team. Perhaps you might notice that bug fixing is climbing. Perhaps that is on purpose. Perhaps not. Either way, you can see it happening and take action.

What do my DORA metrics look like?

DORA Metrics are easy to track in LinearB, again, via a custom dashboard:

Team Level Engineering Metrics

Just as executives need a view into their software development team’s engineering metrics, so, too, do Dev Managers and Dev Leads. They are interested in more day-to-day metrics that track how things are progressing with their specific development pipelines. Dev Leads and Dev Managers want to remove workflow blockers, set goals for workflow optimization, and keep code — and thus value — working its way through the development pipeline.

Why look at team-level engineering metrics?

Dev Leads and Dev Managers want to know the answers to questions like:

Where are my bottlenecks?
Are my developers aligned to business priorities?
Is the team effectively working together?

Where are my bottlenecks?

Bottlenecks can be easily spotted by drilling down into Cycle Time:

It couldn’t be easier — anything that isn’t green is a bottleneck for the team. If you need to, you can drill down into the team and project level to see what is causing the bottlenecks.

Are my developers aligned to business priorities?

The Pulse View can tell a Dev Lead exactly what her team is working on. The Pulse View melds information from your git repository and your Project Management tool to provide valuable insights into what each team and team member is doing.

Below you can see four of the twenty issues that the entire team is currently working on. The view shows active, merged, and shipped work for each project. More and bigger dots mean more activity on a given issue.

Is the team effectively working together?

Ensuring that the team is working together and all rowing in the same direction is a large part of a Development Manager’s job. Out of the box, LinearB provides three team-level dashboards — they are called Quality, Delivery, and ThroughPut — that provide insights into the team-level engineering metrics that are useful for Development Managers.

A large part of the teamwork on a software development team is ensuring the smooth, steady flow of Pull Requests. Keeping an eye on Pull Requests and their corresponding Code Reviews is as easy as setting up a custom dashboard:

Here you can see things like how long it takes for a Pull Request to be picked up and a review started, how much time is being spent on reviews, the depth of those reviews, and more. All of this information can be used to find bottlenecks in your coding pipeline.

Repo Level Engineering Metrics

LinearB’s newest view is the Repository Level view into your codebase. This is best seen via pre-built and custom dashboards. You can create a specific dashboard and then choose to look at it with either the “People” or “Repository” view. This enables you to quickly and easily peer into a specific repository from any dashboard.

Why look at the Repo level metrics?

It is quite common for a larger project to be broken down into multiple repositories. While a view into what a team is doing, sometimes multiple teams are working together on a repository and the status of that repository can become a concern.

Or perhaps your project is based on the microservices model, and you have a repository for each service. With the Repository Level View, you can see what is going on inside the repository for any of the services that may need your attention

Now, with LinearB’s new Repository Level View, you can easily check the health of a given repository.

Here’s a thorough example of a dashboard that will give you insight into a repository as opposed to what your team or organization is up to.

This view has been broken down into three areas of interest by the row of the dashboard:

Quality metrics in Orange
Review success in Purple
Code throughput in Green

The three quality metrics are:

Code Rework — This measures the amount of committed code that are changes to existing code created less than 21 days ago. LinearB recommends that you keep Code Rework to under 3% for any given repository. If you see it going above that, you will know that you have code quality issues or that requirements are changing or not well defined.
PRS Merged without Review — This number should be zero — a flat line across the bottom. There should never be a merge (above a configurable minimum size) that isn’t reviewed. A lack of code review could mean low-quality code has been merged into the repository.
PR Size — Large Pull Requests cause all kinds of problems, including low Pickup Time, Long Reviews, and Pull Requests with low Review Depth. Pull requests should be small and easily digestible. LinearB recommends that Pull Requests average less than one hundred changes. We also recommend that if they get above two hundred changes, then it could indicate problems discussed above.

The three review success metrics are:

Pull Request Pickup Time — PR Pickup TIme is the amount of time between the Pull Request being submitted and the first comment is made on the Pull Request. LinearB recommends that you keep this to less than one day so changes are fresh in everyone’s mind. If the Pull Request Pickup Time starts rising, it likely indicates that other developers are hesitant to start reviewing code, perhaps because they are too busy with Work in Progress or because the Pull Request is large and complex.
Review Time — This is the amount of time spent reviewing the code. If it is too little, say less than a day, it could indicate that reviews are superficial. If it is too high, more than four or five days, it likely means that the code is complex and difficult to understand, and thus difficult to approve.
Review Depth — This is the average number of comments per review. If it is below two, it indicates superficial reviews. More than five, it could indicate complex or hard to understand code needing attention from leadership as the pipeline might be slowed down.

The two code throughput metrics are:

Pull Requests Merged — Here, there is no prescriptive measure. Rather, it is a trend that should be monitored. If it starts lowering, perhaps the development team is stuck or has too big of a project. If it starts rising, that is generally considered a good thing, as Pull Requests are likely small and easy to process.
Deployment Frequency — This is a DORA Metric (which are usually tracked at the executive level) but the measure can also be useful at the repository level. If a repository is being released less weekly, then it indicates features building up that increase the feedback loop for the development team. It also indicates that deployments can get large, and failures become harder to track.

A dashboard such as this one provides a clear look into an individual repository, allowing you to ensure that the code therein is of high quality, being properly reviewed, and moving along quickly into the hands of customers.

Leveling Up Your Development Pipeline

Whether you are a Development Lead or a CTO/VP of Engineering, or if you are concerned with high-level, team-level, or repo-level metrics, LinearB can provide you with the information and insight you need to make sound decisions about your software development process.

Our tool lets you recognize that there is a problem, dig in to find where the problem originates, and take the necessary steps to correct things. If you are not already using LinearB and want to do things like see exactly what is going on in your organization, team, or repository, sign up for a free demo of the product today! Our produce is free to use for teams of eight or less, so get started with a demo today!

Originally published at https://linearb.io on August 9, 2021.

Those “Pesky” Pull Requests are Totally Worth It

Nick Hodges — Fri, 20 Aug 2021 16:01:45 +0000

Pretty much everyone does code reviews. They’ve been around a long time. I remember back in my Borland days when the Chief Scientist would come in every morning and review all the code that had been checked into the Subversion(!) repository the previous day and send emails out to folks whose code wasn’t up to snuff. That’s old school.

Slightly less old school? Saving all the check-ins up until Friday for the Dev Leads and/or Dev Managers to review and approve. Both of these techniques leave a lot to be desired — the main thing being a complete lack of interaction between the developer, the code, and the reviewer.

Code Reviews have a number of purposes. Probably the most important one is preserving the quality and integrity of the code in the repository. Even the two old-school ways above do that.

But almost as important is the learning opportunity that code reviews can provide. If the only feedback a developer gets from a code review is mistakes in formatting or other trivial things like that, then nobody learns and gets better. The old school ways above provide for few opportunities for a developer to increase their skills. To provide learning opportunities, code reviews evolved into meetings where everyone looked at the code written that week and commented on it, criticized it, or otherwise ran it through the gauntlet. This did provide a learning opportunity for developers, but it took more time, as it was 100% synchronous and required all code to wait for the next scheduled meeting to be reviewed.

Now, almost no one is doing these old-school code reviews anymore. All the cool kids are doing pull requests. (Some folks call them “merge requests.”) Pull requests have a number of advantages over the previously mentioned methods, including:

Being done completely asynchronously, but in public for all to see.
No one needs to wait to review the code — it can happen almost immediately after a pull request is issued.
A history of all the comments stays with the code in a repository. This allows a developer to come back to the code a year later and see all the thought that went into writing it.
Pull Requests can be tracked, monitored, and measured. A whole lot of good things can come out of that .

Should you do code reviews at all?

Interestingly, some say no, you shouldn’t.

Not only is Jessica Kerr a great speaker and a good Twitter follow, but she also has some interesting ideas about code reviews in her article of March 27 entitled “Those pesky pull request reviews .” In fact, she doesn’t like pull requests, and argues that you should sidestep them by just working on a given task as a team, so that everyone sees everything as the work gets done.

She believes that pull requests work great for open source projects where a “team” is really a set of individuals coordinating work together. For true development teams, she believes that if a team all works together on a single task, everyone learns and understands the code, and thus there is no task switching between coding and doing pull requests because the pull requests are unnecessary.

Jessica’s idea is radical — basically going beyond Pair Programming and moving into mob programming. Mob programming is the idea of having whole teams work together on projects in serial rather than individually in parallel. Mob programming can eliminate the need for pull requests by causing all of the communication and learning to take place during the coding phase, without any review.

Not a Fan

I’m having a hard time agreeing with her idea for a couple of reasons:

The transaction costs are too high. It seems to me that having four people work on a project together makes for many communication channels, increases the likelihood of interruptions, and reduces the amount of code that will actually get written. It’s sort of a “Too many cooks spoil the broth” notion.
It doesn’t capture the discussions and history that will remain long after the code is committed. One of the most important and powerful benefits of pull requests is the learning that can take place during and even long after code has been reviewed and deployed.
Finally — not all projects are conducive to multiple team members working together. Some are small and multiple people working together would be overkill. Some are esoteric and require the focus of one person. Some will match the team and can be worked on together. There’s no one size fits all solution for all projects.
Finally, not doing pull requests pretty much eliminates all the benefits of metrics systems like LinearB . Tracking the progress of pull requests and code reviews through the pipeline is a critical process for knowing how your team is performing. Without that, you can't measure things and if you can’t measure things, you can’t improve.

As part of a discussion about code reviews, Rob Kraft, one of the Development Leaders in our vibrant Dev Interrupted Discord Server (you should join!) made the following comment that I agree with:

I think that what Jessica needs is a good look at LinearB. 🙂

Let me address some of her more specific objections:

“Let’s face it: nobody wants to review pull requests.” Well, I don’t think that is true. We here at LinearB see customers every day that are doing pull requests efficiently and effectively. Sure, pull requests can be hard and nobody wants to do them if you aren’t correctly incenting the team to create pull requests that are easy to review. No one likes a huge pull request. But through monitoring metrics like Pull Request Size, you can encourage your team to create small, easy-to-review pull requests. And voila! People don’t hate pull requests anymore.
“They’re a social interaction minefield!” People complain that code reviews can cause strife on a team. Well, so can conversations during Mob Programming. I’m not sure that I see a distinction. And if doing a code review causes strife, then you have a cultural problem that no development methodology is going to solve.
“We could blame the people. We could nag them more. We could even automate the nagging!” Well, if code reviews are small, concise, and easy to do, “automating the nagging” via our WorkerB product is usually more than enough to get the ball rolling and keep it rolling. Notifications and tracking of any reviews that do happen to languish keep things moving as well. LinearB customers have seen drastic improvements in code pipeline productivity as a result of this so-called “nagging”.
“Maybe instead of trying to work a bit more together, we could work together.” Well sure, but if you do that, checking in code without a process of pull requests and code reviews, well, then you aren’t getting all the benefits listed above, nor those of a metrics tool that can show you what your Cycle Time is doing. And I don’t believe that mob programming will prevent the cultural problems that can arise from code reviews. People will be people whether in a mob programming environment or in an asynchronous code review process.

Bottom Line

Okay — so what rubber is hitting the road here?

If pull requests and code reviews are hard and people don’t want to do them, then you are doing them wrong. So the trick is to make them easy to do.

We here at LinearB see many, many customers improve their Cycle Time and their overall software development process by using and tracking pull requests. By combining metrics tracking around pull requests with tools like WorkerB, many, many development organizations have seen smaller pull requests, better reviews, shorter Cycle Times, and an overall sense that things are really humming.

Monitoring things like the size of pull requests, when pull requests are assigned, picked up, and commented on, as well as monitoring the depth of reviews that take place all create an environment of small, discrete, easy to review pull requests.

And of course, if you want to find out more about what our customers already know, you can book a free demo of LinearB .

In the end, while her ideas are intriguing and thought-provoking, I can’t say I agree with Jessica’s argument. There doesn’t seem to be any good reason not to do pull requests with code reviews.

Jessica’s blog post can be read on her Jessitron blog and you can follow her on Twitter at @jessitron

If you haven't already heard, Dev Interrupted is hosting INTERACT: The interactive, community-driven, digital conference that takes place September 30th. Designed by engineering leaders, for engineering leaders, INTERACT will feature 10 speakers, 100s of engineers and engineering leaders, and is totally free.

Register Now

If you haven’t already joined the best developer discord out there, WYD?

Originally published at https://devinterrupted.com on June 30, 2021.