The Need For Speed

I got involved in a discussion on Twitter the other day. Someone had asked for opinions on Feature Branching. I responded that I thought it was flawed because people think it is faster to work in parallel, but when you take into account the cost of resyncing it is actually less efficient. Joerg immediately pointed out that speed is not the only metric and it may not be that important. When I pressed him, he responded that he is most concerned about manageability. I'll let you read the Twitter thread and draw your own conclusion about Joerg's point. In this post, I want to examine why I think speed is in fact one of the most important metrics.

An Important Caveat

The first caveat when we talk about speed is that we can't sacrifice quality for speed. Our code doesn't have to be perfect, it never will be. There is a certain level of quality where if you drop below that, you slow down because your code becomes hard to read and maintain. We want to set a quality bar that gives us a good margin above that. Each team will have its own acceptable level of quality and we want to make sure we maintain that. Sometimes quality is the first thing developers throw away in pursuit of going faster, so I wanted to make sure to clarify upfront that sacrificing quality is counterproductive and not the way to go faster.

Why Speed?

If you read my posts on maxims to code by, you'll remember seeing the phrase: "Favor Faster Feedback" That is exactly why I care about speed. The faster my cycle time, from idea to code to customer, the faster I can detect problems and correct course. This works on several levels. On a micro level, getting fast feedback from my tests and my continuous integration system helps me to avoid bugs in the code and keep the code quality high. On a macro level, getting working software into my customer's hands faster means I find out exactly what they want faster. It also helps to maintain good relationships with my customers because they can easily see the progress.

The Sam Evaluation

If you look at my The Sam Evaluation, you'll see it hits on the idea of speed - note the last question in each of these groups.

• Describe what happens from the time a developer makes a change until they can verify that all the tests pass and the application builds? How do you ensure that process is fast and repeatable?
• Describe how you take a built application and get it into the hands of your users. How do you ensure that process is fast and repeatable?
• Describe your bug-fixing process. How do users report bugs? How are they tracked? How do you prioritize them? How do developers fix them and release the fixed code? How do you ensure that process is fast and repeatable?

DORA Metrics

It's not just me that thinks that speed is important. If you look at the DORA Metrics from the Accelerate book, you'll see that out of four metrics, the first three are based on speed and the last one on quality.

The 4 DORA Metrics are:

• Deployment Frequency - How often do you deploy to production?
• Lead Time For Changes - How long does it take for committed code to make it to production?
• Mean Time To Recover - When you find a problem in production, how long does it take to fix?
• Change Failure Rate - How often do your deployments introduce problems in production?

These metrics aren't perfect, but taken together and tracked over time, they can be useful for judging how efficient your software development process is. They aren't great at measuring if you are delivering the right software, but they are great at measuring how quickly and reliably you can churn out high quality software. Presumably if you are delivering usable software often and putting customer feedback back into your process, you should be producing the "right" software - ie. something valuable to your customer that solves their problem.

If you are new to the DORA metrics (or even if you aren't) it is worth listening to this exchange between Allen Holub and Dave Farley. Allen is actually highly critical of them, but for good reason, while Dave defends them.

How Do We Go Faster?

Saying we should go faster (while maintaining quality) is easy, but how do we actually do it in practice?

Many More Much Smaller Steps

You have probably heard me use this phrase many times. It's not my phrase, it comes from GeePaw Hill, but I have adopted it. Basically the idea is to "slow down to go fast". I know that it sounds crazy, but instead of rushing headlong into things and tackling the problem as initially presented, we first take a step back and break things down into as small chunks as possible, and then iterate on those chunks. If you don't know where to start, I like the Mikado Method a lot for the act of actually breaking the work down.

There are many advantages to taking smaller steps. Since the steps are smaller, we are making fewer changes, which means fewer opportunities for bugs. This keeps the code quality higher. Smaller steps allow us to deploy more frequently. This gives us the opportunity to introduce feedback more often. The small size of the changes makes it easy to respond quickly to that feedback. I can't say enough about the benefits of working in smaller steps.

True CI/CD and TBD

In order to go fast, we have to have Continuous Integration/Continuous Delivery (CI/CD) in place. We have to be able to quickly and easily verify that our code builds and is free of known bugs. We also have to have a way to get that code into our customers hands. This stuff has to be automated. The easiest way to do this is to use Trunk Based Development (TBD) and avoid unnecessary feature branching and merge requests, which can act as bottleknecks. This brings us back to the original conversation.

Mobbing and Pairing

Coming full circle to the original conversation, the real problem with feature branching is that it is built on the assumption that parallel is faster. It seems faster, but every asynchronous process requires re-synchronization and that has a significant cost. I've been convinced lately that if you really want to go fast (and I've outlined why you should), then mobbing is the way to go. It eliminates the re-synchronization time. There are also lots of other benefits. If you don't believe me, start listening to the Mob Mentality podcast. It will change your mind.