Wednesday, April 20, 2005

The Principles of SCM

I think many of the principles of good system/software design apply to the design of an "SCM Solution Architecture". In particular, I think many principles of sound Object-Oriented Design (OOD) are applicable since a lot of OOD deals with managing and minimizing dependencies through the use of techniques and mechanisms like: encapsulation, abstraction, information hiding, modularity, composition, delegation, inheritance, and polymorphism.

One set of fairly well known OOD Principles was written by Robert Martin in 1996-1997 as part of a series of articles in "The C++ Report". (See the ObjectMentor webpage for their OOD Principles training course -- halfway thru the page it has an "articles" section with links to copies of the original articles that appeared in the C++ Report.)

These Principles of OOD were also in his 1995 book "Designing O-O Applications Using the Booch Method". Then Robert started evolving and developing them more, and also working with patterns, and then eventually extreme programming practices. And what was going to be a 2nd edition of the book instead became a 10 year "project" that combined these principles, with patterns, and agile development "practices" into a new book that came out in November 2002 called "Agile Software Development: Principles, Patterns, and Practices"

These "Principles of OOD" are ...
Principles of Class Design:
  • (OCP) The Open-Closed Principle
  • (LSP) The Liskov Substitution Principle
  • (DIP) The Dependency Inversion Principle
  • (ISP) The Interface Segregation Principle
Principles of Package Cohesion:
  • (REP) The Reuse/Release Equivalency Principle
  • (CCP) The Common Closure Principle
  • (CRP) The Common Reuse Principle
Principles of Package Coupling:
  • (ADP) The Acyclic Dependencies Principle
  • (SDP) The Stable Dependencies Principle
  • (SAP) The Stable Abstraction Principle
Maybe it would be the case that, when "translated" into SCM concepts and terms ...
  • Class design principles would translate into baseline and/or configuration derivation and composition principles?
  • Package cohesion principles would translate into change-task and/or change-set cohesion principles?
  • Package coupling principles would translate into codeline and/or variant management principles?
And these would give me guidance on things like ...
  • How small or fine-grained should my change-tasks minimally be?
  • When & how often should I commit and/or promote new baselines?
  • How should baselines relate to other baselines and codelines?
  • How should codelines relate to other baselines and codelines?
  • How should I manage dependencies between changes/branches/codelines?
These guidelines would (ideally) manifest themselves as various "SCM patterns" for a given problem and context. Each "problem" would correspond to a situation that is a potential violation of one or more principles (anti-pattern), and the pattern solution would figure out which principles are being bent or broken and how to resolve that without bending or breaking one of the other principles too much as a result.

What do you think are some of the principles of Software CM?

No comments: