Informing someone that you want to “measure” them is not a great way to start a conversation. Software developers, like all people, tend to look unfavorably upon having their performance closely measured. But measuring developers is one of the hottest trends for companies around the globe. So is it tyranny to measure people?

People are quick to note that numbers don’t tell the whole story and can become defensive at the notion their productivity should be quantified somehow. This resistance can become even more entrenched when teams become stacked against each other. 

Many leaders - like Netflix's Kathryn Koehler - believe we should absolutely avoid stack ranking of individuals and teams. After all, the human elements of teams - communication, coordination, leadership - can all affect the speed or perceived productivity of a team or process, so how can you quantify that? 

Thankfully, plenty of tools exist to enable a data-driven approach to the development process. With the right approach, these tools can be used to enhance any individual’s or team's performance. Beyond performance, when applied correctly, these tools can bring about more harmonious alignment between leadership and employees. 

But first, why do we measure? 

Why measure at all? 

It’s important to remember that measuring is just a tool -- it can be used for both good and for evil. An effective leadership team understands this basic fact. The cool thing about metrics is that they provide insight that might otherwise be difficult to obtain. Employees should note that good leadership will use metrics merely to inform their decisions, not solely drive them.

As a basic rule, it is difficult to improve something that is not measured.

I started with the really basic observation that I believe you cannot be sure that you're improving something if you don't measure it, right? I mean, think of trying to lose weight without weighing yourself. -Luca Rossi, from the Dev Interrupted Podcast at 4:31

Measuring creates a foundationa benchmarkwhich can be built upon. Once this foundation is established, organizations can begin to set goals. If you can set goals, you can rally a team; and if you can rally a team, you can achieve your product goals. This all becomes easier when you adopt a quantitative approach to your process. Success flows from the foundational element that measuring provides. 

Lastly, there exists a psychological benefit to measuring: namely, that people implicitly understand that metrics which are measured are important. After all, no one measures something they don’t care about. That which leadership identifies as measurable naturally informs employees what metrics leadership thinks are important. The very act of deciding to measure something telegraphs your intentions. Inversely, the opposite is also true: people tend to believe what is not measured is not important. 

All of this means leadership should be careful to identify what metrics are important because they define your organization and its behavior.

What should be measured?

First, an organization must decide what metrics are worthy and whether or not they are actionable. A lean approach is best here. Decide what does and does not matter to you, and then move confidently in that direction. 

So what metrics are worthy to an engineering team? 

There are many valid metrics which include things like Velocity, Branch Coverage, and Cycle Time, but one of the most interesting metrics we care about at LinearB is the Pull Request. In fact, it’s kind of our thing

A pull request has two major goals: the first is to improve the quality of code before you release it, while the second is to share knowledge between the team about the code base. 

Pull Requests are great because they let your team have control over what goes into git; they let people comment about what and why things were done a certain way; and they can serve as permanent documentation about a chunk of code that can be useful down the road.

If we at LinearB were to recommend one metric to start measuring, it would be Pull Request Size. Measuring PR Size -- and using that measurement to encourage smaller Pull Requests -- will help drastically lower Cycle Time. It will encourage all kinds of good behavior around code reviews, and it will prove that metrics can have a positive impact on business outcomes.

Once you have identified the best metrics to track for your success, you will need to go about making sure they last. Here it is best to maintain a lean approach, avoiding large upfront investments of time or money. 

How to make metrics stick

Image shows Luca Rossi and his title: Head of Engineering at Translated

And you should, as a leader, as a manager, you should make people feel that you care. There is no substitute for that. - Luca Rossi, Dev Interrupted Podcast at 21:10

We have all worked at a company where a change was decided, people were excited to see the change and then, after a couple of months, everyone has forgotten about it. Metrics are no different. Once a company makes the decision to align itself with a metric it must make the effort for it to last. 

It’s often best to start small. In the beginning, it is best to maintain a lean approach, avoiding large upfront investments of time or money. With small actionable change in mind, there are two ways to approach metrics adoption:

  1. In a top-down approach you ‘ll want to speak with your senior developers early on. Give them strategic input to help them figure out the best way to implement metrics into your dev team. An engineering leader can then explain how the metrics fit into the company’s strategic direction and convey that message clearly to employees. It is important to get buy-in from your employees because they are the ones building value, and further discovering what can and should be measured. When done correctly, the top-down approach will have managers saying, “Wow, I’ve always wanted to measure this. Now I can.” 
  2. In a bottom-up approach, it’s all about making your team understand what you want to achieve. Provide them with the initiative to build value so they understand why and how they are being measured. For instance, most developers can relate to a bad pull request experience - one that takes way too long or one that has a poor review and causes issues during production. People understand that a good code review should be both fast and accurate. So by starting small with a metric that is already understood, you will gain buy-in from your team. When done correctly, the bottom-up approach will have employees saying, “Wow, we didn't think we could measure this, and it's actually valuable.”

How you approach adjusting for change in the long-term is up to you. In an ideal world, both the top-down and bottom-up approaches would be utilized simultaneously.

Most importantly, your people should know that you care and that you value their feedback. 

Bottom Line

To achieve future goals a development team should know where it started. Metrics provide that benchmark. They are a foundation on which future success and business alignment can be built. 

Furthermore, in engineering, just as in life, tiny improvements are staggering when tracked continuously over a period of months and years. These gains boost team confidence and collaboration. 

Because with continual improvement, people feel as if they are working within a team and working as a team. When things go right, and everyone improves together, bonds are formed.

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

I included a few quotes from Luca Rossi above. He has a great blog for those who are passionate about engineering. You can check it out here: 

Who says developers can't be the life of the party? Come see for yourself why the Dev Interrupted Discord has emerged as the go-to community for developers. Growing from 0-1400+ engineering leaders in just the past 8 months, our community is attracting the attention of CTOs and VPs of companies like Netflix, GitHub and Google. Join the community.

Managing the software development process has been likened to herding cats. In other words, you can’t really do it, but you can sure give it the old college try. 

It’s no secret that managing the development of a software project is an imprecise science. Here are nine truisms that I’ve learned over the years that have helped me to understand the limitations of our ability to manage the strange world of software development projects.

1. Estimates Are Always Wrong

Whether you estimate something at one hour or one year, your estimate is wrong. That’s just the way it is. They won’t necessarily be extremely wrong — they might only be a little bit off — but they will be wrong.

If you look at a bug report and think, “That will take an hour to fix,” it almost certainly won’t take an hour. It might take 45 minutes, it might take three hours, but the chances of it taking exactly an hour — even give or take a minute or two — are slim. Now, you might say, “about an hour” instead. That’s a better estimate because actual, precise estimates are wrong.

Now for short projects that might take an hour, this isn’t a big deal. But…

2. The Bigger the Project, the Less Accurate Your Estimate Will Be

The bigger the project, the less precise the estimate will be — especially if estimation takes place at the very beginning of the project. As with the hour estimate above, if you estimate a project at a year, it might take nine months or 36 months. In some cases, it might take five years. There is no way to know when the project is starting out.

The bigger the project, the more “unknown unknowns” there are. There are usually more people involved. That is, as a project’s size increases, there are more variables and more things that will happen that you cannot anticipate. All of these things will add time to the project that you can’t plan for at the beginning because by definition you don’t know that they are going to happen.

3. Focus and Concentration Are Our Most Valuable — and Scarcest — Commodities

When building software, the single most valuable thing required to complete a project is the ability of the developers on the team to concentrate in an undistracted manner.

The fewer distractions, the more productive the team will be. It’s really that simple. One of the main responsibilities of a software development manager is to reduce the number and duration of distractions to the team.

Software developers, when left alone, can be quite productive. When they are interrupted — whether for meetings or by people asking questions or anything else — they can lose that productivity very quickly. We all know about “flow” and how hard it is to get into the flow and stay there. That flow time should be valued like bitcoin and protected as such.

4. Hofstadter’s Law Is the Truth

Hofstadter’s Law is stated as follows:

“It always takes longer than you expect, even when you take into account Hofstadter’s Law.” — Wikipedia

This is related to estimates, but it’s important to note the beauty of this aphorism. You can pad your estimates because you think it will help buy you time to get things done. You can add in extra factors, plan for “unknown unknowns,” and increase your estimates to take into account the belief that it will take longer than you think, but in the end, it will still almost always take you longer than you think to get a project done.

5. You Can Only Run in the Red for Very, Very Brief Periods

You can demand the team put in more hours, come in on weekends -- all those “crack the whip” kinds of things -- and you might get some (very) short-term gains out of that.

But if you try to make it the norm — if you try to run your team's engine at the red line of RPMs on a consistent basis — you will burn out the engine. You will see diminishing returns pretty quickly. Employees will leave. People, like race car engines, cannot be overstressed for extended periods of time without breaking down.

6. Brain Time Is More Important Than Butt Time

This one is so important, I wrote a whole blog post about it.

Nothing will decrease productivity more than demanding Butt Time (i.e. that your developers be seen sitting in their chairs for hours on end). You can measure Butt Time and feel like you’ve got a metric that will really show how productive people are being. But you’d be wrong. Demanding Butt Time will demoralize a team that really wants to spend Brain Time.

Brain Time is what really matters. Think about it this way: Let’s say you are a manager and it is most important for you to see your team sitting at their desks “working.” You wander around the office seeing those developers sitting in their chairs, pounding away at their keyboards. All is well with the world.

But then you run across one developer, and they’re just sitting there staring at their screen. That’s it. They’re sitting and staring. For like half an hour. What the heck! They’re not doing a thing!

But of course, they are. They’re thinking. They’re spending Brain Time solving a very difficult problem. Maybe they even get up and wander around the building for a while. In the end, they sit down, type 11 lines of code, and mark a user story complete.

Did they meet your “Butt Time” criteria? No. Did they produce an elegant solution to a very difficult problem? Yes.

Butt Time proves nothing. Brain Time means everything.

7. Hardware Is Cheaper Than Developer Time — Way Cheaper

Developers are expensive. You pay competitive salaries to attract top talent. An hour of their time is not cheap. Despite this, many companies don’t realize the incredible value of an hour of a developer’s time and skimp on hardware for the team.

But come on, computers are expensive! That extra RAM will bust the budget for hardware!

Well, it might bust the budget, but that’s because you’ve got a budget problem.

Look at it this way: Let’s say that you pay a developer $100,000 a year — or around $50 an hour. Let’s say they spend an hour a day waiting for the compiler to do its work. However, you could add some RAM and a faster processor to that developer's machine and cut that time down to 45 minutes a day. You save 15 minutes a day. At 200 days a year, that is 50 hours. At $50 an hour, that is $2,500 saved per developer per year. But what if the incremental cost of the faster machine is $500?

You get the point. If you have 20 developers, getting the faster machine saves you $40,000 for a $10,000 investment. That ought to be a no-brainer.

And that is only for the faster compile times. Everything else they do will be faster as well.

If your budget doesn’t allow for faster machines, then you need to adjust your budget.

8. If You Haven’t Read “PeopleWare”, Then You Aren’t Really a Software Development Manager

As far as I’m concerned, there is but one book that will teach you how to manage software developers: Peopleware by Tom DeMarco and Timothy Lister (be sure to get the third edition…).

This book is excellent, insightful, to the point, clear, and pulls no punches. It is full of wisdom about managing software projects and software developers. It is timeless.

Read it.

9. Quality Is a Perception — Not a Bug Count

This one is really hard to accept.

Here’s the basic premise: You can have close to zero bugs in your bug tracker and people can still think your software is buggy. You can have a large number of bugs in your bug tracker and people can think your software is as solid as a rock. There’s no correlation between the number of bugs in your tracking system and the perception of the quality of your software.

Now I’m not arguing that you shouldn’t try to reduce your bug count — quite the contrary. But in the end, your software can only be said to be of high quality if your customers perceive it that way — and your bug count won’t necessarily dictate that. Weird, huh?

And while we are on the subject, what does it mean to have a “high” bug count? What is the definition of “high” when your codebase has 100,000 lines of code? 5 million lines of code? Who’s to say?

Embrace Flexibility

Bringing a software project in for a safe landing on a short runway is a challenging and difficult proposition under the best of circumstances. Add in the ambiguities and all the things that can go wrong along the way, and it’s a miracle anything gets done. Development managers need to be flexible and take things as they come

The trick is to accept and understand those ambiguities and to work with them — not against them. Accepting these nine truisms will help with that.

Sponsored by LinearB

Want to reduce a lot of that ambiguity?  LinearB can closely track what is happening in your software pipeline, enabling more brain time, and automating things that require butt time. 

Book a demo today and find out how you can drastically reduce your code delivery times and continuously improve your development process.


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 2000 members, the Dev Interrupted Discord Community is the best place for Engineering Leaders to engage in daily conversation. No salespeople allowed. Join the community >>

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:

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:

  1. 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. 
  2. 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. 
  3. 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.
  4. 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 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:

  1. 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.
  2. 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. 
  3. 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”.
  4. 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 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 2000 members, the Dev Interrupted Discord Community is the best place for Engineering Leaders to engage in daily conversation. No salespeople allowed. Join the community >>

Open source software has been around for quite some time, but as I highlighted on the Dev Interrupted Podcast, only within the last decade has it come to be widely accepted and used, though many organizations are yet to use the concept. While many people still remain skeptical of open source, its growing popularity and use is undeniable. 

For many developers, open source is “the one true way”, almost a religion. Many of the world’s best and brightest developers devote themselves to creating and advancing the cause of open source projects. There are any number of foundations and organizations--from The Apache Software Foundation to the .NET Foundation--that openly support open source. Open source is a large part of some of the biggest tech giants in the world, including Google, Microsoft, and Amazon.

Benefits of Open Source

As the VP of Engineering of, which has entirely embraced the open source benefits model, I am an open source “true believer” and see many benefits to using open source software. I highlighted five of these key benefits on the Dev Interrupted Podcast with LinearB co-founder Dan Lines:

1. Open source is widely used

What development organization doesn’t use git these days?

There are many open source projects that are widely used. Tools like Elastic, Kafka, and the Apache Web Server are amongst the most popular and commonly used software applications in the world. Because they and many other similar projects are so popular, there are copious resources available for learning, troubleshooting, and solving problems. 

Finding developers that are skilled in a particular project can be much easier, as these projects are so widely used and known. Plus, developers prefer to work at companies that use open source, because they know that they won’t be locked into a proprietary solution and that their skills will be transferable. 

2. Open source is responsive

Open source is usually very responsive to issues and bug reports, often delivering fixes and updates in days or even hours. These updates can often be deployed immediately whereas with proprietary software, you often have to wait months for the next release to resolve a problem.

New features are available earlier in the development cycle, and users can normally see and try out features as they develop. This enables organizations to more rapidly adopt new versions of projects.

3. Open source brings financial advantages

Open source can both cut costs and minimize maintenance. Of course, the biggest cost benefit comes from getting a complete, proven software package for no cost. Improvements and bug fixes also come to the software from external sources, keeping maintenance costs low. Development occurs outside of your organization, resulting in new features with little effort.

Using open source just makes financial sense. I don’t want to write a load balancer--why should I spend the time and effort to do so when I can use one built and maintained by experts?

Sure, there are some costs associated with open source, such as setup time, learning time, and continuing maintenance and configuration, but the same costs are incurred for closed source software. 

4. Open source is more secure

Security is a worry with any software that you use, and some argue that open source isn’t secure because everyone and anyone can see what the application does--but I say that open source software is more secure because of this.

“What do you trust more? Security in a product that is fully transparent, where you have tens or hundreds of workers across the world testing and working on it, as opposed to a product where you have not seen the source at all.“ 

-- from the Dev Interrupted Podcast at 8:20

Since everyone and anyone can see the code, they do know exactly what the software does and doesn’t do. Thousands of pairs of eyes from all over the world look at the code and can spot vulnerabilities before they are exploited.  Thanks to this transparency, it’s much more difficult to take advantage of security holes because they’re fixed as fast as they are found.

Proprietary software doesn’t have this advantage. It only has a single development team looking at the source, and you as a consumer have no idea what security holes may lurk within.

5. Open source is future-proof

One of the benefits of open source is that it can never disappear. A proprietary company can go out of business, leaving you high and dry and with no options but to stick with what you have or migrate to another solution.

However, open source is available, well, forever. Put a project up on GitHub, and it will live as long as someone has the source code. 

In a worst case scenario, an organization can take over the project themselves, fixing things and adding features as desired. 

Managed Service Providers

Open source software very commonly lends itself to the managed service model. In fact, most managed service providers would not be open source-able without open source software. A proprietary solution cannot be used in such a manner -- the licensing would forbid it. Taking open source and providing it as a service is a powerful business model that is only possible because of the open licensing of open source.

We here at provide managed services for log and tracing analytics and observability. We use a number of open source projects to provide these services. Our value, like all managed service providers, lies in our ability to provide expertise for a service that another organization probably doesn’t want to spend the time and money to become experts in. This is only possible because of open source.

Is open source for everyone?

No -- open source software is not for everyone. 

Some organizations--especially large, enterprise companies--are not able to risk the “infection” from licenses like the GPL. Large organizations often have legal requirements that prevent them from safely absorbing open source. Some organizations simply can’t or won’t overcome NIH -- the “Not Invented Here” syndrome. Some want a company that they can yell at if something goes wrong. And some people just don’t see “the one true way”.

This is the Way

In the end, I truly believe that the benefits of open source vastly outweigh any costs that may be incurred. We’ve staked our whole business on it here at, and it’s clearly working not only for us but for many other companies and managed service providers. Fully and clearly considered, it’s hard to see why your company couldn’t benefit from using open source Software.

Listen here if you want to learn more about the benefits of enterprise open source software. 


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 2000 members, the Dev Interrupted Discord Community is the best place for Engineering Leaders to engage in daily conversation. No salespeople allowed. Join the community >>