Principles of Agile Version Control: From OOD to TBD

[article]
Summary:
In this article, the authors discuss the principles of version control that help enable agile development. With an understanding of the principles of object-oriented design, as well as the principles of agile development, they can derive the principles of agile version control. We focus on the principles of object-oriented design (OOD) and how we can use them to derive corresponding version control principles for task-based development (TBD).

In this article, we will discuss the principles of version control that help enable agile development. With an understanding of the principles of object-oriented design, as well as the principles of agile development, we can derive the principles of agile version control. We will focus on the principles of object-oriented design (OOD) and how we can use them to derive corresponding version control principles for task-based development (TBD).

Symptoms of Poor Version Control

If agile and iterative development constantly integrate, build and test software in very small increments, how can we ever have stable baselines or codelines? How can we ever propagate fixes or enhancements from legacy releases to the current under-development release and make sure we aren't doing too much branching, merging and baselining? How can we make sure that the branching, merging and baselining that we are doing follows a simple, yet structured fashion that safeguards the integrity and reproducibility of the software without hindering productivity and development creativity?

Robert Martin describes several symptoms of poor design in [1] that translate quite readily into symptoms of poor version control:

  • Rigidity/Inertia: The software is difficult to integrate and deploy/upgrade because every update impacts, or is impacted by, dependencies upon other parts of the development, integration, or deployment environment.
  • Fragility/Inconsistency: Builds are easily “broken” because integrating new changes impacts other fixes, features, or enhancements that are seemingly unrelated to the change that was just made, creates changes keep disappearing and reappearing, or are difficult to identify/reproduce.
  • Immobility/Inactivity: New fixes, features, or enhancements take too long to develop because configurations and their updates take a long time to integrate and propagate or build and test.
  • Viscosity/Friction: The “friction” of the software process against the development flow of client-valued change is too high because the process has an inappropriate degree of ceremony or control.
  • Needless Complexity/Tedium: Procedures and tasks are overly onerous and/or error prone because of too many procedural roles, steps, and artifacts or are too fine-grained “micro” tracking/status-accounting and possess an overly strict enforcement or rigid and inflexible workflow.
  • Needless Repetition/Redundancy: The version-control process exhibits excessive branching and merging, workspaces, or baselining in order to copy the contents of files, changes and versions to maintain multiple views of the codebase.
  • Opacity/Incomprehensibility: It is difficult to understand and untangle the branching, merging, and baselining schemes into a simple and transparent flow of changes for multiple tasks and features developed from multiple collaborating teams that are working on multiple projects from multiple locations for multiple customers.

Why do these things happen?  They may happen for a host of reasons. They happen because the practitioners involved haven't yet learned or appreciated the importance of sound version control principles and practices, and haven't suffered the consequences of not following them. Or perhaps they have suffered the consequences but they don't understand why. It may be blamed on the wrong thing, such as trying to prevent change when they need to simply make change easier.  It may be that practitioners try to overcompensate for something “bad” that happened by going too far to the other extreme.

What's a seasoned veteran version-control practitioner to do?  They do what they've always done! They use sound practices and judgment honed from years of experience to recognize these symptoms and their underlying problems, identify which principles have been violated, and then apply the appropriate SCM patterns [2] for their particular context.

Many of the practices that help us recognize and resolve these problems come from what is commonly called change-based (or change-oriented) versioning and task-based development. The corresponding principles have much in common with the principles of object-oriented design.

Pages

About the author

About the author

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

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