Saturday, May 05, 2007

Software CM is Not a Process!

The (hopefully) provocative title of today's blog-entry is inspired by Phil Armour's essay "Software is Not a Product!", which is one of many profoundly insightful essay's from his book The Laws of Software Process.

Armour maintains that:
The core issue with the business of software is that we misunderstand what software really is. Software is thought of as being a product, it is looked at as being a product, it is mostly managed as if it were a product. But it's not a product... The hard part about creating software systems is not creating them, it is in acquiring the knowledge necessary to create them (correctly).

    Software is not a product, it is a medium for storing executable knowledge.

Our lack of understanding of this basic fact is one of the key issues facing the software industry. We do not "build systems"—we acquire knowledge. The systems we ship to our customers are actually the byproducts of the real activity, which is to learn.

The business imperative is that the real product is the knowledge that is in the systems we ship to the customer, and we don't manage that at all.

So today, I'll attempt a similarly-themed "riff" about Software CM, beginning with the assertion that Software CM is not a process!

This assertion might seem shocking to some. Other CMers might say they have known this all along, saying CM is a discipline (rather than a process), and that numerous formal definitions of SCM have said this for quite some time: SCM is a "discipline" that "governs" or applies "technical and administrative direction and surveillance" to the functional components of CM (item identification & planning; item storage, versioning & change control; status accounting, audit & review).

If software is a medium for storing executable knowledge, and software development is a knowledge acquisition & creation (learning) activity, then the result of software CM is the medium through which software development changes and collaborative learning must ultimately flow.

If the result of software CM is a medium for the conveyance of changes by executing the knowledge gained from learning, then software CM itself must impose some form of order (structure & rhythm) to achieve this resulting collaborative flow of change-flow.

For me, terms like "order" and "structure" evoke memories from my years participating in the software patterns movement and study+discussion of the works of Christopher Alexander. For Alexander, patterns were all about discovering the innate order in structures that emerged naturally from the recurring attempt to resolve (trade-off) the same set of competings concerns (forces) for the same problem in the same/similar contexts. The resulting structures and their sequencing and interaction is what all comes together as an overall (emergent) architecture.

Hence, I would say that Software CM is an emergent yet intentional architecture that ensures the orderly, efficient flow of software development change & collaboration.

The elements of this Software CM architecture include practices, tools & technology, teams & organizations, valued deliverables & intermediate work-products, changes to and assemblies of these deliverables & work-products, and the set of needed status/tracking reports & measures.

Hmmn, this fits in rather nicely with my 4+2 Views of SCM/ALM Solution Architecture and perhaps even does a good job of tying together SCM with Agile/Lean (collaboration & flow), and software patterns (particularly SCM Patterns :).

So there you have it:
Software CM creates the medium through which software development changes & activities must flow. Therefore, Software CM is the intentional architecture of software development change-flow.

What do you think?


Simon McClenahan said...

If we are taking terms literally, doesn't the "Management" M in CM imply some sort of management process is taking place? And all processes executed according to design is a discipline.

By asserting that Software CM is not a process, would you also assert that Software Development is not a process?

Maybe I'm misunderstanding the article, but it seems to me that the discussion is akin to evolution (process) versus design (intentional architecture).

Most software professionals have a goal with requirements that must be met and requires intentional architecture, which would define a software product. Hackers, startup companies, R&D software development can write software to see what can be useful from it, which can be an (evolutionary) process, if you also believe that programming can be a form of art.

Brad Appleton said...

Hi Simon! I think we could certainly infer some sort of management process is taking place. I'm not sure I would consider that correct. Certainly some degree of management and process is happening, but also a whole lot more. And I certainly wouldnt infer that some form of "architecture" is taking place, yet I'm maintaining that is precisely what is going on.

Like Armour's article, mine is about adopting a different mind-set and approach to thinking about what CM actually is, and how that might "change" the way we should be trying to do it.