Sometimes, You Just Need to Slow Down

While it may seem that slowing things down is undesirable, such approaches often work very well and produce a higher throughput than the original (seemingly more active and energetic, if perhaps rather more frenetic) process. The downside of these experiences is that they make it easy to confuse manage with control, and even easier to interpret control as inhibit.

Software Development teams deliver value by writing new code or by changing existing code and functionality. The majority of the time it is about changing existing systems, and not writing completely new ones. Software configuration management is one of the disciplines responsible for managing that change. Rapid, unmanaged, change can cause chaos and reduce productivity.  

One (easy) way to reduce that chaos is to reduce the frequency of change. Most of us have experienced situations where order has been been created out of chaos by slowing things down and controlling changes so that they are, perhaps, grouped together in releases, reviewed and authorized before being allowed to happen.  Rapid, well-managed change is a mechanism for delivering value more quickly.  Rather than simply managing change, SCM can be a tool for enabling change that will maximize the value of the system being developed.

A traditional SCM approach for managing change is isolating streams of work to reduce the immediate impact on other streams when changes are made to another. While this provides short-term gains, it also defers the cost of integration until a later, perhaps more sensitive, point in the project. By realizing that branching is not the only tool teams can us to manage change, and by using simple codelines and good engineering practices, your team can develop new features in an integrated manner, thus isolating streams of development and not incurring the associated cost of branching and merging.

Applying the Principles of Lean Development to Branching
The principles of lean development, as applied to branching are:

  • Eliminate waste: Eliminate avoidable merge-propagation, long-lived variant branches, and stale code and partially completed work
  • Build quality in:  Maintain codeline integrity with an automated unit & integration tests and a Codeline policy to establish a set of invariant conditions that all checkins/commits to the codeline must preserve.
  • Amplify learning:  Facilitate frequent feedback via frequent/continuous integration and workspace update
  • Defer commitment:  Branch as late as possible. Create a label to take a snapshot of where you might have to branch from, but don't actually create the branch until parallelism is needed.
  • Deliver fast:  Complete and commit change-tasks and short-lived branches (such as task-branches, private-branches, and release-prep branches) as early as possible
  • Respect people:  Let developers reconcile merges and commit their own changes (as opposed to some dedicated integrator/builder)
  • Optimize the whole:  When/if branches are created, use the Mainline pattern to maintain a leaner and more manageable branching structure

In other words, branch when it makes sense, but realize that branching has a cost.  Also, branching is not always the best tool for managing change.

If you favor eliminating waste and the other principles of lean branching, working on a single codeline (when in the past you might have favored a branch) requires a commitment on the part of the development team to maintain the simplicity necessary to make this process work.

Simple Codelines and No Broken Windows
For teams to make progress, you need to keep the codeline functional. In the words of the pragmatic programmers, "clean, functional systems deteriorate pretty quickly once windows start breaking"  [ENTROPY]. If the codeline is always working, it's easy to migrate new functionality by using adapters or to add modules for new functionality without integrating them tightly into the existing code. One way of viewing this is as simple codelines. The Rules for simple codelines are:

  • Correctly build, run (and pass) all the tests
  • Contain no duplicate work/work-products
  • Transparently contain all the changes we needed to make 
  • Minimize the number and length of sub-branches and unsynchronized work/changes (see Lean branching)


About the author

Brad Appleton's picture Brad Appleton

Brad Appleton is a software CM/ALM solution architect and lean/agile development champion at a large telecommunications company. Currently he helps projects and teams adopt and apply lean/agile development and CM/ALM practices and tools. He is coauthor of the book Software Configuration Management Patterns, a columnist for the CMCrossroads and AgileConnection communities at,  and a former section editor for The C++ Report. You can read Brad's blog at

About the author

Steve Berczuk's picture Steve Berczuk

Steve Berczuk is a Principal Engineer and Scrum Master at Fitbit. The author of Software Configuration Management Patterns: Effective Teamwork, Practical Integration, he is a recognized expert in software configuration management and agile software development. Steve is passionate about helping teams work effectively to produce quality software. He has an M.S. in operations research from Stanford University and an S.B. in Electrical Engineering from MIT, and is a certified, practicing ScrumMaster. Contact Steve at or visit and follow his blog at

About the author

Robert Cowham's picture Robert Cowham

Robert Cowham has long been interested in software configuration management while retaining the attitude of a generalist with experience and skills in many aspects of software development. A regular presenter at conferences, he authored the Agile SCM column within the CM Journal together with Brad Appleton and Steve Berczuk. His day job is as Services Director for Square Mile Systems whose main focus is on skills and techniques for infrastructure configuration management and DCIM (Data Center Infrastructure Management) - applying configuration management principles to hardware documentation and implementation as well as mapping ITIL services to the underlying layers.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!