Testing's Role in the Software Configuration Management Process

"The 80/20 Principle" refers to research on differences in performance between 40 medium sized German companies. The most profitable companies were all simpler than the others - they had a stronger understanding of and focus on what was important and kept working at it.

The fundamental 80/20 rule (also known as Pareto's Principle after the Italian Economist Vilfredo Pareto who first noticed the relationship) is a challenge to us to think about and observe what activities in our lives and work that we typically spend 20% of our time on, actually generate 80% of the results (and the figures don't have to be precisely this ratio - it might be 70/30 or 95/5). If we can identify the 20% that really makes the difference, and we double it - can we achieve 160%? The challenge is there.

Interestingly Koch gives the advice to set impossible targets for your teams, because this by its very nature will cause them to focus on the 20% of value. This has a kernel of truth in it, and perhaps achieves the same result as agile practices which focus on business value. This is inspite of seeming to contradict the extreme programming "no overtime" practice.  Brad has written in his blog ( Simple Ain't Easy ):

I think that true simplicity is about minimizing and managing overall complexity. Complexity in software design and development comes from the sheer size and complexity of the problem we are being asked to solve, and the richness and vastness of the interconnected maze of interactions within the system and between the system and its environment. The overall complexity of the system is dominated far more by the interactions between the parts that makeup the whole than it is by the parts alone.

For any non-trivial system, simplicity often has less to do with the number and kind of different things involved and more to do with the number and kind of interdependencies between them. So achieving simplicity is less about managing "parts" of "things" or individual point-solutions, and is more about managing rules and relationships between the parts and things and solution-sets.

When dealing with large or complex systems (like most software, and software processes) the number of things (scale) and different types of things (diversity) that need to be managed is overwhelming. If we can come up with a modicum of modest, simple rules & principles to govern our design decisions in ways that help us minimize and manage interdependencies, eliminate constraints, and remove waste, then we are on the path to solving the real problem and meeting stakeholder needs in a way that is both simple and sustainable.

Testing and the Product Development Ecosystem 
Software Configuration Management Patterns starts with the idea that how your software configuration management is part of the larger context of your development environment, which includes the product architecture, your organizational structures, and, we can now add, your testing strategy. For example, a product development organization that has a highly modular architecture, high communication between product  and very good test coverage might find it self need to branch less frequently as variations are addressed by the modularity and stability concerns by test coverage. Likewise an team with a Big Ball of Mud architecture and poor test coverage may feel the need to maintain multiple codelines.

The SCM Pattern language is one mechanism for illustrating where testing fits in to the process. The SCM Pattern language was written with the idea of building a system where you can be agile, lean, and minimize unnecessary branching.  Let's talk about that and then cover how you can