How to explain source control and best practices to non-technical managers?

Question

My manager recently asked, "Is there a standard procedure or process that is typically used by businesses to ensure the file integrity of files -- maintaining their separateness from those that are involved in work-in-progress projects -- yet permitting all necessary users to gain access to the most up-to-date and accurate files?"

Of course she's talking about source control, which we do have and use but we've had some problems lately with some remote team members not using it properly. How do I explain the basic principles and practices of source control to someone non-technical so that she can understand it well enough to know if the people she's managing are doing it right? I'd prefer something written -- a book would be nice but something on the web is fine -- because her attention span for verbal explanations of technical stuff from me is not good. My first instinct was to give her "Code Complete", but on second thought that's probably far too technical. Any suggestions would be appreciated.

(The projects in question are built in C++ and ASP.NET using Visual Studio 2005 and SourceSafe, if it matters.)

Answer 1

Eric Sink wrote this:

http://www.ericsink.com/scm/source%5Fcontrol.html

It's a mix of high-level and technical.

Answer 2

An excellent introduction is the book by Wayne Babich 'Software Configuration Management', which is now old but still very readable, and the fundamentals have not changed. It is relatively slim, and the last chapter, describing a particular Ada IDE, is essentially ignorable except as a source of ideas. It does not cover DVCS; that might be an issue for you since your remote users are not playing well with the VCS you are using.

Note that this assumes that 'sending the manager to read something' will work. Even if it didn't, you might be able to use some of the illustrations (Bill Barnstormer and Co still exist) and get the ideas for a quick presentation on the subject - being cautious about copyrights in the illustrations. You could use it as the reference behind your presentation, anyway.

Answer 3

What managers should be interested in is Return on Investment (ROI) if it neither makes not saves money (and time is money, and so is error reduction), it has no value to a buisness (even if it makes its workers happy). Your source control vendor probably already has an ROI whitepaper intended precisely to sell the product to managers - use that.

If you are using an Open Source tool with no such document, use someone else's, and emphasise the additional savings from using Open Source.

Also Source Control is number 1 in The Joel Test: 12 Steps to Better Code and that is an easy read for a manager.

The Wikipedia article of SCM is also pretty straightforward.

[edit]Found also A Visual Guide to Version Control which seems to cover all the technical aspects in a clear and concise manner.

Answer 4

Don't explain the how, explain the why:

Storing a history of the code so that changes to the code can be audited and tracked back to individual developers and feature/bug fix requests.

Also, being able to roll back to a previous version.

Branching allows to separate a stable, released version (where you apply only critical bug fixes) from development on the next version.

Diffing and merging tools integrated with source control make help developers aplying these critical operations correctly.

Integrating with additional tools, you can create a workflow that matches the requirements of your company, defining the interfaces between planning/marketing, development, quality control and help desk/support.