Principles of Agile Version Control: From OOD to TBD


Principles of Object-Oriented Design


The principles of object-oriented design [1] address the need to minimize the complexity and impact of change by minimizing dependencies through the use of loosely coupled and highly cohesive classes, interfaces, and packages. These are the logical containers of software functionality and are realized in “physical” containers of version control (configuration elements).  These exist in the form of files, libraries and components, and are as follows:

Principles of Class Design


The Single Responsibility Principle

A class should have one, and only one, reason to change.


The Open-Closed Principle

A class should be open for extension (of its behavior) but closed against modification (of its contents).


The Liskov Substitution Principle

Derived classes must be substitutable for (require no more, and ensure no less than) their base classes.


The Dependency Inversion Principle

Depend on abstract interfaces, not on concrete details.


The Interface Segregation Principle

Make fine grained interfaces that are client specific.


The Law Of Demeter
(Principle of Least Assumed Knowledge)

Objects and their methods should assume as little as possible about the structure or properties of other objects (including its own subcomponents). [3]


The "Don't Repeat Yourself" Principle

Every piece of knowledge should have one authoritative, unambiguous representation within the system. [4]

Principles of Package Design


The Release Reuse Equivalency Principle

The granule of reuse is the granule of release.


The Common Closure Principle

Classes that change together are packaged together.


The Common Reuse Principle

Classes that are used together are packaged together.

Principles of Package Coupling


The Acyclic Dependencies Principle

The dependency graph of packages shall contain no cycles.


The Stable Dependencies Principle

Depend in the direction of stability.


The Stable Abstractions Principle

Abstractness increases with stability.

We wish to derive similar principles for version control using the logical containers of change-based versioning and task-based development:

  • Changes
  • Workspaces (sandboxes)
  • Versions (labels/tags)
  • Configurations (builds & baselines)
  • Streams (codelines)

The resulting version control principles should address the need to minimize the complexity and impact of change by minimizing dependencies through the use of loosely coupled and highly cohesive, correct and consistent changes, versions and codelines. We must be mindful of the notion of time when deriving these principles in order to properly and accurately translate their meaning from the domain of classes and packages to the domain of version control.

In addition to terms like classes and packages, we will also need to translate the meaning of terms like abstract, interface and stability into the domain of version control:

  • Classes and packages might correspond to any of the aforementioned types of entities (changes, workspaces, versions, configurations, codelines). An instance of a particular class is an object.  Each object has its own behavior, state (its data or contents), and unique identity. Previously published notions of container-based/component-based SCM are a precedent for this frame of thinking (see [5]-[8]).
  • An interface might be some set of identifying characteristics or acceptance criteria that is common to a set of items (e.g., instances of configurations), or to a particular state of an item.
  • Abstraction/abstractness is somewhat different from the above. The more broadly used a container is, the more it serves as a basis for subsequent ongoing evolution, just as the more abstract a class is, the more it serves as a basis for subsequent derivation. This relates to the liveness or velocity of the flow of change/activity for an item's contents. A more conservative flow tries to conserve present value, while a more progressive flow attempts to add value at a faster rate of progress.
  • Stability corresponds to the dependability of an abstract container or the reliability or safety with which one can depend upon it to preserve the interface or invariants of the container. This directly relates to the level of quality assurance of an item. The stability of a container is the extent to which its contents are of consistently reliable quality.
  • Change is Evolution! Most times when the principles of OOD refer to change or modification, it means evolution in the context of version control.

With the above terminology translations in effect, we are now prepared to attempt translating the principles of OOD into version control principles, and to explore their validity and applicability.

The Principles of Task-Based Development (TBD)

About the author

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.