Code Lines

My last post introduced the series. This post defines some terms and sets the stage for discussing the value of simple branching for agile teams

A Code Line is a progression of the set of source files and other artifacts which make up software components as they change over time. A Branch is a kind of Code Line. People often use Branch and Code Line synonymously, but since branch implies divergence, I like to useCode Line as the more general case, and Branch for Code Lines that diverge from the main source code line (the Main Line).

Some of the names I (and others) use for branches come from the Streamed Lines paper. Software Configuration Management Patterns (SCM Patterns Book) identifies Code Lines based on how they are used and also provides some guidance about how code lines and testing practices fit together to help Code Lines be more agile. An article by Martin Fowler also names code lines.

Since 2002, when the SCM Patterns book was first published, source code management tools like Git tools have improved such that some of the patterns in SCM Patterns are already built in. The mechanics of branching and merging are easier, but knowing when to apply the techniques still matters. Even with information and better tools teams still struggle with maintaining Code Line structures that work well for them.

More powerful SCM tools make it easier to have more complicated structures. Sometimes more complexity is necessary, but it can often be a warning sign of a sub-optimal approach. Some teams use complex Code Line structures to compensate for risks that that other parts of the process — such as planning and testing — introduce. The planning ecosystem and testing practice has a huge impact on how well your process works:

Agile Code Lines, Testing, and Agile Planning need to work together for any of those parts to work well

Code Lines can define a framework to help you be more productive, but the best code line structure can’t fully compensate for all other problems.

Next I’ll talk about how Code Lines fit into the larger development process, and why they are worth thinking about.