My Notes

Software Development Bandwidth

Adnan Mujkanovic -

Intro

Software development is a non-trivial endeavour. The goal is to deliver value to customers as fast as possible while staying in line with business goals and keeping quality at a high level. As we know from experience, fast and high quality usually don't work well together. Let's see what we can do about it.

What Is Lead Time?

Lead time in software development refers to the total time elapsed from when a requirement or feature is initially identified until it is successfully delivered and deployed into production for end users.

Lead time encompasses the entire value stream, including time spent in backlogs or waiting for resources, coding, testing, approvals, and deployment.

Shorter lead times indicate higher agility and responsiveness to customer needs and market changes.

Long lead times can signify bottlenecks, inefficiencies, or constraints in the development workflow that need to be addressed.

Tracking and optimizing lead time is crucial for software teams as it directly impacts their ability to rapidly deliver value to customers and stay competitive. Reducing lead time is a key goal of DevOps and agile methodologies.

How To Optimize Lead Time?

Since lead time involves many steps and stages, we first have to look at all these steps and try to identify where to start. To optimize lead time we can use the "theory of constraints" to help us identify bottlenecks.

What Is The "Theory of Constraints"?

The theory of constraints (TOC) is a management philosophy and methodology developed by Eliyahu M. Goldratt. It is based on the principle that every system has at least one constraint that limits its performance relative to its goal.

The throughput of the entire system is limited by its constraint. Improving non-constraints will not increase throughput.

What Is The Constraint?

Lead time in software development can have many constraints like:

  • Policy constraints like unnecessary approval gates or handoffs between siloed teams (dev, testing, ops)
  • Lack of team expertise or having too small/large a team size
  • Unclear requirements or frequent scope changes leading to scope creep
  • Resource constraints like insufficient hardware, tools or development environments
  • Dependencies on external services, APIs or components that cause integration delays
  • Poor communication and collaboration within the team or with stakeholders

As usual, every organization is unique and should analyze their specific context to understand what the constraint is they should focus on.

But in this article I will focus on one particular constraint - batch size.

What Is Batch Size?

The batch size in software development is the amount of code changes going through and waiting in the pipeline (review, approval, acceptance, QA) before being deployed into production.

What Is Bandwidth?

Bandwidth is a measure of the maximum data transfer capacity of a network or internet connection. It refers to the amount of data that can be transmitted over a network in a given time period.

If you try to send more data than the available bandwidth can handle, it will result in packet loss and degraded performance.

The Analogy

The simple analogy I will use here is that the software development value stream has a certain amount of bandwidth.

If you try to push more through the stream than the available bandwidth can handle, it will result in slow and degraded performance, less agility, more bugs, etc.

Less Is More

This is one of those problems where the solution is counter-intuitive. This means that if we want to be more agile, deliver value to the customer faster without compromising on quality, we have to deliver less at a time.

By delivering less at a time we gain the following benefits:

  • Easier writing of automated tests
  • Increased automated test coverage
  • Faster code reviews
  • Easier catching of issues during reviews
  • Higher code quality
  • Faster feedback cycles
  • Faster response to information
  • Less technical debt
  • Lower cognitive load
  • Increased developer satisfaction
  • Actual continues integration
  • Easier refactorings
  • and more ...

How To Implement Smaller Batch Sizes?

Unfortunately, we cannot implement this over night and with only good will. It requires change in mindset and some new ground rules i.e. constraints.

Some recommendations are:

  • Start small on a fresh smaller size project
  • Do smaller projects in general
  • Split user stories and tasks
  • Pair Programming
  • Write automated tests (easier since changes much smaller)
  • Use red-green-refactor cycle
  • Use the "branch by abstraction" pattern
  • Do synchronous code reviews
  • Deploy changes every day or morning as a rule
  • Decouple deployment from release through feature flags
  • Use trunk-based development

Conclusion

Sometimes less is more and this is the case for many software development teams. To deliver value to the customer faster and with a higher quality, we need to understand that the value stream pipeline has a limited bandwidth and we need to act accordingly. Maybe this is not the solution for your team, but maybe it's worth a try.