Fog Creek Software
Discussion Board




Is CM meaningfully covered in CS programs?

To you developers out there, esp those with CS academic backgrounds:

I'm curious to know whether you folks got any instruction or training in configuration management prior to getting out 'in the wild'.

My degree and background is in engineering, but not CS. However, I have several times had situations arise in shops I've been part of where **I** was the champion of CM, and in fact knew more about the overall need, process and use of particular tools in CM than a number of the developers--some fairly senior folks. I consider myself good, but not expert at CM.

What has surprised me is first, that I should even be the champion--I can't understand how fairly senior developers could ever not be as strong advocates of CM as I am, and second, that I should know more about how to implement it.

I'm reasonably intelligent (get my shoes tied correctly every morning-and without help anymore ;-), and I'm certainly not surprised when the developers know tons more about how to architect a system, for example. I'm just completely surprised that senior developers would not know way more than I about simple stuff like labeling builds and being able to check out by label; I mean this ain't rocket science. The hell of it is that the organizational 'juice' normally lies with the developers, not with QA, so I normally lose the argument when I prepare a procedure and workflow for a project detailing specific CM steps, the procedure gets ignored (and I can't enforce it), then weeks or months later, the inevitable happens and I watch people scramble around trying to handle propagating maintenance changes across branches of code when they haven't been tracking what files have gotten altered with each change request (eventhough the particular CM tool makes it just stupid-easy to do)

I've seen this sort of issue in several shops now.

Are my expectations of developer's appreciation for and understanding of CM too high?

Thanks,

anonQAguy
Monday, February 03, 2003

What's CM?

Tipsy McStagger
Monday, February 03, 2003

configuration management

no its not covered in any program i've seen but it's easy to pick up and practiced everywhere i've been so i don't see it as a problem

Dennis Atkins
Monday, February 03, 2003

At the risk of sounding ignorant, I've never heard of it.

WNC
Monday, February 03, 2003

I've not heard of it either; at least, not by that name.

Do you have a link pointing to a good summary? I can think of a lot of things that CM might mean, but none of them really make sense :)

So far, the CS program here at GVSU has not mentioned that acronym.

Mike Swieton
Monday, February 03, 2003

i thought it was Content Management when I saw the Topic.

Colleges mostly teach you theorical stuff.

Prakash S
Monday, February 03, 2003

Configuration Management is often used as a synonym for source control, though it really goes a bit beyond that.  It's often referred to as Software Configuration Management or SCM.  Search google for that and you'll get tons of hits.

Somebody
Monday, February 03, 2003

Hmm. Interesting set of responses so far.

fyi, here's a link to an SEI paper I found in a couple minutes of looking. If you goto the bottom of the page at the link below and click to get the pdf, that's the whole paper, I think. I didn't read it, I only scanned over the front page--it gives a definition and a bit of description of SCM.

www.sei.cmu.edu/legacy/scm/abstracts/abscm_concepts.html

My own brief description of CM or SCM, is that it is essentially the process by which changes to software artifacts are tracked and controlled.

Before the XP supporters (and I consider myself one as well) get all hot and bothered about the use of 'controlled' in such proximity to 'changes', SCM is not a mechanism for stopping or reducing change in any way. It simply describes the field of endeavor by which you can change your software artifacts as you need to without inflicting self-injury--knowing what you changed, who did it, how, and why.

Bare source code control by itself is a subset of SCM, but I guess it's probably the component of SCM developers see most frequently and probably is why it's often the first thing that comes to mind. As other examples, in a shrinkwrap environment, all sorts of things may be tracked configuration items: the master disks that go to the sub contractor who runs the assembly line where the software is loaded into the bare systems, the controlled build environments on which all but dev builds are done, the development environment (e.g. OS and compiler versions and setup parameters), change requests (I'm using the term to include both enhancement requests and bug reports), a CCB (configuration control board - they meet to analyze and evaluate the impact of proposed system changes and to select features for upcoming releases, or to make decisions regarding patches), are all potentially parts of a CM process.

Realizing that software artifacts are going to change, SCM tries to keep it from becoming a chaotic grab-ass.

anonQAguy
Tuesday, February 04, 2003

Oh, and Dennis -

I'd say that at it's most 'anal' manifestations, a CM system can get fairly complicated perhaps, but I agree with you that for a hell of a lot of projects, the basics are not hard to grasp at all--neither the need for them nor their implementation.

Indeed, CM isn't supposed to get in your way, the mission is to develop the software system properly, not serve a CM process.

Anyway, what you said is kind of how I had thought of it too, hence the surprise I expressed in my original post.

I guess I'm going to have to push to have a little professional development session for our developers and fill in this gap.

anonQAguy
Tuesday, February 04, 2003

Ahh, I am now understanding what you're getting at now.

While it's a small data point, here's an answer from here: no. I've not heard anything yet that suggests that anyone in the CS/IS department here at GVSU teaches any of those concepts.

On a tangent: it seems like CM would be split into two categories: pure code-related things (CVS), and management things (assembly line, etc.).

The pure CS program here will probably never cover the management ends, and I doubt they'll cover the source things, as I'm not satisfied with the way they cover more central topics, like on designing large systems.

Maybe MIT does it well :)

Mike Swieton
Tuesday, February 04, 2003

There is a continuum that goes something like

version control <->product data management<->configuration management<->knowledge management

KM seems to be about who interacted with whom on what in the modern enterprise but should rathwer be about product line engineering.

The traditional cm stuff falls far short of what is required in product line engineering

Karel
Tuesday, February 04, 2003

I am 'Mister CM' at my work, In most smaller shops the Build Guy ends up being the CM Guy (Note Build Management is part of CM according to the IEEE) here is a quick over view of CM from a DOD Journal of SE:
http://www.stsc.hill.af.mil/CrossTalk/2003/01/leishman.html
and then you have http://www.daveeaton.com/scm/CMFAQ.html
The CM FAQ.

cheers
MAD

A Software Build Guy
Tuesday, February 04, 2003

And to answer the orignal Post: NO,  I believe this is one of the failings of CS education in the US.

A Software Build Guy
Tuesday, February 04, 2003

Software Build Guy - thanks for those links; I just checked them out briefly and they look like good ones I'll need to bookmark.

I appreciate it.

Cheers,

anonQAguy
Tuesday, February 04, 2003

As a CM specialist it was kind of interesting reading all these posts!!! Especially those who had not heard the term (although almost inevitably will be doing some form of informal CM).

What I didn't see mentioned was the word CHANGE.

This is what CM is mostly about; Managing CHANGE to products.

It's also about understanding what your products are their inter-relationships (e.g. a product hierarchy)

Change creates new versions (which must be managed), new builds (which must be made), new releases (which must be released). It's not just about version control. And it's not just about version control of source code. Documents and testing artifacts must also be managed.

It's also about baselining; capturing the collective versions of all the bits that make up a product or part of the product.

We need to create baselines at multiple points throughout the development of a product change; when the requirements are signed off, when the design is approved, for each formal build, for each phase of testing. At each point we would baseline appropriate components of the product (e.g. business requirements, design docs, test scripts, test data, source code, built components). The approach is created to be appropriate to the development methodology in use, whether RAD, waterfall. agile etc.

It's also about planning and controlling releases of builds and the final product.

The major problem with CM is that there is no standard 'standard' for CM; not even for the definition of what it is. IEEE zealots claim that they have a standard.. except very few people have ever seen it.. mostly because the IEEE 'own' it and charge for copies. ITIL claims to cover CM but only from a Operational environment side and not from a development perspective. The CM Institute (CMII?) claim a standard... but it isn't. The German V-Model has a lot of CM in it as does Prince. All different!

Of course whilst CM maintains it's ill-defined and mystical qualities it means guys like me can remain employed!

Gwyn
Tuesday, February 04, 2003

Karel,
CM is a coherant  artifact management system of a software product and has nothing to do with either knowledge management systems (systems that are self contained expert information retreivial and semiautomous AI systems) nor do they deal with product data management.  In fact I believe that the IEEE says that CM is identifying, tracking, and versioning of all information of a that effects product development weather Hardware or software

cheers
MAD

A Software Build Guy
Tuesday, February 04, 2003

>here's an answer from here: no. I've
>not heard anything yet that suggests
>that anyone in the CS/IS department
>here at GVSU teaches any of those concepts.

I also attend GVSU; ferguson teaches it in his Software Management Classes.  Of course, those are grad classes, taken by Sr. Developers and wanna-be managers. 

We used the term, uh ... "Configuration Management."  After a couple of weeks of struggle, we gave up and just use the phase "Source Code Control System." (VSS, CVS, etc.)

Of course, some poor fool is going to post that "REAL" SCM allows you to manage CHANGE on projects with over-lapping codebases with different products, blah, blah, blah.

There are some good arguments there to help manage very large products.  But, for the most part, it's hard to get faster by -adding stuff- to your process.  In order to really get faster, you've got to take stuff out.

I guess I'm saying that Source Code Control has a place, and it should be taught in the undergrad CS cirricula, but it currently isn't (enough), and it's not the holy grail.

just my $0.02 ...

Matt H.
Tuesday, February 04, 2003

Gywn,

What about the US DOD http://www.pogner.demon.co.uk/mil_498/
and what about SPICE
http://www.sqi.gu.edu.au/spice/
The US DOD has had a number of Systems Mentioned and documents.
The IEEE CM Doocuement cost only around 500 USD and includes all SE standards that the IEEE has produced (The CM only doucuments cost around 100 USD)  That last figure is the cost of two or three books on any software topic.


All:
here is a site of CM links
http://www.snuffybear.com/ucmcentral_new_cmportal.htm

cheers
MAD

A Software Build Guy
Tuesday, February 04, 2003

Matt H said: "There are some good arguments there to help manage very large products. But, for the most part, it's hard to get faster by -adding stuff- to your process. In order to really get faster, you've got to take stuff out."

Matt, you're completely correct!  And with the **right** amount of SCM **in** your development process, what you're taking **out** of your process includes:

1) wasting time attempting to manually re-edit code to roll-back changes
2) wasting time chasing errors (including false errors) arising from having files out of synch with each other
3) wasting time dealing with support calls, and the associated expense of re-shipping user manual revisions because the user manual version sent out wasn't the right one for the version of the application sent out -- because somebody didn't know how to do a simple lable in their source control tool and the project team didn't have the awareness and discipline to bother including the documentation team and their products in SCM
4) wasting time trying to debug a problem because you don't know what the exact build environment was of the software you sent out the door.
5) having the testers waste time trying to figure out WTF new features and bug fixes were included in the latest build so they can focus on them; because there's no connection established between the labeled build and the change requests/requirements/bug reports, etc.

Yes, you're absolutely right -- you speed up by removing things from the process; the key to actually having the process speed up during the life of a project and not simply during the next five minutes is to remove the **correct things** from the process. Namely things that waste time, examples of which I've listed.

Not everything that uses time is wasting it, of course. It seems that teams frequently can't spare the time to set up a simple SCM procedure and adhere to it, but when it blows up in their faces (after I warned them, dammit) they can sure afford to spend the time to try to manually recreate things and try to go back and manually figure out which files were altered to satisfy which enhancement request, when all this takes is a couple of extra seconds at each operation to let the tool do this for them.

So the key, as many folks have cited in a number of threads is to not be penny-wise, pound foolish. It seems very easy for developers to see this when the topic is how nice a chair, monitor, workstation, cube/office, etc. they are going to get. It seems somewhat more difficult, however, when it's a QA guy telling them they're going to shoot their toes off unless they use their CM tools properly and follow procedure. WTF - he's just a QA guy and dammit we just don't have the time to do all that procedural crap. I'm not trying to put words in your mouth, Matt -- just venting a bit in frustration over the incident that spawned my original post (as folks probably guessed by now).

take stuff out, definitely...just take out the right stuff.

anonQAguy
Tuesday, February 04, 2003

>>> "The IEEE CM Doocuement cost only around 500 USD and includes all SE standards that the IEEE has produced (The CM only doucuments cost around 100 USD)  That last figure is the cost of two or three books on any software topic."

Any standard you have to pay for is not going to become a universally accepted standard. And I'm not actually sure that the IEEE standard is meaningful unless you're integrating it with following the other IEEE standards as only this provides a full management solution.

And yes, there are plenty of other claimed standards but they are only really standard within the context of a larger proprietary standard framework!

>>> "There are some good arguments there to help manage very large products.  But, for the most part, it's hard to get faster by -adding stuff- to your process.  In order to really get faster, you've got to take stuff out."

This is SUCH a classic reaction!! Perhaps I ought to recant the hare versus the tortoise fable?

Unless you're in a very small (like 1 person) environment you WILL benefit from adding change management to your processes.

You get faster because you generate fewer problems, because you only make approved changes, because you can find the components that went into last month's build of the product. You save money because you understand the cost of making changes before you do them, because the customer (if you develop bespoke software) agrees to pay for the changes and because you have a change agreed with the customer you prevent expensive scope creepage.

When I was contracting at ICL an audit was done of an internal product development. The customer (an internal customer) had agreed to pay £45k for the provision of a system but there was no formal change control and then the scope creepage started. When the audit took place over £1m had actually been spent developing the product and it still wasn't finished to the customer's satisfaction! This is certainly excessive but by no means not untypical.

There is a paradox that exists; only when you follow CM disciplines are you able to measure the cost of not having CM!

Gwyn
Tuesday, February 04, 2003

In a previous job, we had to solve some difficult problems of versionning (branches, floating branches, etc ...).

We decided to use Starteam (formerly Starbase now Borland) and I would recommand it.

The acquisition price was high, but I guess CM can be so complex and bound so deeply with internal process that it can't be cheap.

The key benefit for us was to put CM responsabilities directly in the hands of the dev team instead of a QA team.

We made this choice because our company was 'technically driven' so the software became the core of all change requests, roadmaps etc ...

I believe this kind of choice would be difficult in a company with a strong QA culture and structure.

Ralph Chaléon
Tuesday, February 04, 2003

>I guess I'm saying that Source Code Control
>has a place, and it should be taught in the
>undergrad CS cirricula, but it currently isn't
>(enough), and it's not the holy grail.

I was trying to say that it current isn't -taught- enough.

You  need VSS or CVS.  You need to a bug-tracker.(preferably, you also handle feature requests with the same software) You need a project tool. (I like MS Excel).

However, I've found that if you apply discipline to the process, and the project is small-ish (<6 man-years), it's possible to avoid forking the codebase toooo much, and you don't need an "enterprise" SCM tool.  (I like VSS and we label every build, thank you very much. :-)

regards,

Matt H.
Tuesday, February 04, 2003

When I was in CS, the SE horizon seemed to be 2 developers for3 months types of stuff. CM was unheared of, as was any other lifecycle or "large scale" stuff.

Just me (Sir to you)
Tuesday, February 04, 2003

You'd be lucky to see CM mentioned in a software engineering course, if anywhere.  Not even source control.  Probably not the end of the world, most people seem to pick it up on the job easily enough, if they get any exposure to it.

Not only is Source Control one of the common manifestations of CM, but so is bug and feature tracking.  If you can get your software together such that Change Request->Prioritization->Code Change->Testing->Code Release is a simple process, and you can easily see the changes that have happened through time, what status current changes are in, and track these changes from the request all the way to the new version of a certain dll, you've reached CM nirvana.

My current company has nothing but VSS, and a couple of email lists.  No proper bug tracking, and a lot of screwed up code branches.  I really want to launch them into the 21st century.

I want the programming team to be able to see where the fires are, and what changes we are looking forward to doing in the future.  I want the guy who releases new versions to our clients to know what the new fixes are.  I want to know that every new feature has been tested.  And I don't want my half-developed feature getting released with my coworker's emergency bug fix.  And I don't want to burden everyone with annoying proccess that is all to easy to "forget"

Keith Wright
Tuesday, February 04, 2003

Easy question with an easy answer:  "Hell no". :)  Hope that helps. :)

Crimson
Tuesday, February 04, 2003

In my college days (Computer Engineering, University of Arizona, 2000), I was treated to about a dozen renditions of the "design process lecture" (usually accompanied with a nice overhead describing circular path describing the specification, research, design, implementation, and testing cycle).  These lectures were big on generalities and short on details that I came away without really learning all that much.  That was really the sum total of my "software design process" coursework.  Only after an internship at a startup (where the process rated pretty high on the Joel Test) did I have some hands-on experience with things like source control, bug databases and test harnesses.  I really could have benefited if my wished my college offered -- or even required -- an "Overview of Software Development Best Practices" course with McConnell as the textbook.  But I doubt if many colleges actually do ...

Alyosha`
Tuesday, February 04, 2003

*  Recent Topics

*  Fog Creek Home