The Buffering Law observed in Software Engineering

Railway buffer at the top of Pikes Peak, Colorado Springs CO

There is an informative slide deck on the FactoryPhysics website entitled A Fast Cycle Time Story. This slide deck was created by two Intel Products employees namely Tim Skowronski and Joan Tafoya.

The slides cover many aspects of lean manufacturing, one of the topics covered is The Buffering Law

Systems with variability must be buffered by some combination of:

  • Inventory
  • Capacity
  • Time

Tafoya and Skowronski explain the implication of this law

If you cannot pay to reduce variability, you will pay in terms of high WIP, under-utilized capacity, or reduced customer service i.e. lost sales, long lead times, and/or late deliveries.

The following variability buffering examples are provided:

  • Ballpoint Pens:
    • can’t buffer with time (who will backorder a cheap pen?)
    • can’t buffer with capacity (too expensive, and slow)
    • must buffer with inventory
  • Ambulance Service:
    • can’t buffer with inventory (an inventory of trips to hospitals?)
    • can’t buffer with time (response time is the key measure)
    • must buffer with capacity
  • Organ Transplants:
    • can’t buffer with WIP (perishable – very short usable life)
    • can’t buffer with capacity (we cannot ethically increase capacity)
    • must buffer with time

In software engineering we experience variability due to a number of reasons, including policies and practices we put in place.  The prominent cause of variability considered here is changing requirements and the varying levels of demand for features.

This variably is due to a number of reasons e.g. a customer gaining insights after using the software, a new opportunity in the market, a change in regulation etc. This variability is largely due to external events. Iterative and incremental development practices help reduce the impact of this variability but this does not illuminate variablility. Therefore, according to the Buffering Law, we need to buffer with some combination of inventory, capacity or time.

We cannot buffer with inventory because we don’t know what the future requirements will be. If we did we would not have variability in the first place.

A teams capacity is their ability to produce features as and when the business needs them. There are a number of options teams can use to improve their capacity e.g. process improvements (Scrum\Kanban), technological improvements (automated acceptance tests), increasing or decreasing team size (two pizza rule).

Due to the nature of software development most teams are continuously trying to catch up with a backlog of requirements. Many of these teams are continuously improving their velocity. With this in mind, it is naive to think that we can cause a huge increase capacity simply because we need to. That is like saying we only take the short cut when we are in a rush. The teams capacity is not like a tap that we can turn on and off. While all teams can (and should) incrementally improve, drastically increasing capacity in times of need it is not always feasible and it is not a trivial task.

In software development we need to buffer with time. Teams aim to deliver the requested features over a period of time. As Tafoya and Skowronski point out, when you buffer with time you pay with “reduced customer service i.e. lost sales, long lead times, and/or late deliveries”. Which reads like a readers digest version of the history of software development.

Photo attributed to: Tim Pearce


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s