Did you forget your: Username / Password ?

Microsoft

TechWell

Home

CM Journal Articles

Do the Right Thing!

Written by Ben Weatherall

Monday, 18 June 2007 11:45

A long time ago my father taught me that one of the most important things I should do in life is to always do the Right Thing. He spent the rest of his life showing me by example how to determine what the Right Thing was in any given situation. How does this fit into this month's topic, "Does Management Fit in Your Project? [Project managers and configuration management practices]"? I will try to illustrate...

Management is a part of any project, regardless of how formal or small it may be. In many cases a project may consist of only one person who will act as Manager, Designer, Developer, Technical Writer, Build Manager and Release Manager. In larger projects, each of these functional roles may consist of entire teams. Regardless, CM beyond building and releasing the final product should be performed - it is just the level of detail, amount of time spent and formality of the approach that varies. In the same way, the larger or more complicate a project becomes, the more formal Management becomes and the more dependent it becomes on other groups providing risk assessments as well as other decision making data/information.

"[1]CM does not stand alone. It is a part of an overall quality process. It works with both Quality Assurance (QA) and Quality Control (QC) to provide an environment that facilitates Products developed in both shorter cycle times and with increased quality. The figure below shows how the services provided overlap.

"Development produces the "source" that is used in constructing the deliverable Product. CM provides the control of Development Assets and insures reproducibility. QC takes the results of a CM controlled build and tests it, recording any defects found. QA performs audits of the developed "source" and combines them with defect data obtained from QC and the change data obtained from CM to determine the overall quality of a Release and to provide feedback to Development on process and practice changes that could be made to increase Product quality. Management is responsible for the timely integration of data from the various groups, provides risk based decisions using data provided from all of the other groups, provides overall scheduling and planning services and in general provides a needed oversight function."

So what is "the Right Thing?" If we look at CM as a governing body that owns the codebase, tools and environments, then the "Right Thing" is the normal formal processes and procedures everyone is used to hearing about. It is an adherence to one or more standards, regardless of the development methodology in use. If we look at Management as a controlling authority with the right to set priorities, schedules and deadlines, then the "Right Thing" is whatever makes that happen without loosing total control of the software assets along the way. But if we work together, then the "Right Thing" is doing what is necessary to ensure the success of the project. This means being willing to bend on non-critical issues and hold fast to certain core principles.

Let's take a look at some of the core CM principles:

No code shall be used in a non-development build unless is has been checked into the Version Control Repository.
All builds that are to be submitted to non-development groups such as Quality Control and Release Management shall be build solely from controlled source in a controlled build environment.
All derived and controlled artifacts that are to be released shall reside in a Read-Only access point (filesystem, database, etc.) where they may be deployed to or pulled from by other groups.
All non-development tests shall be done on the results of a controlled build.
All releases to external agencies (customers) shall be done using the results of a controlled build.

Note that there is no mention of Requirements or Designs, nor is there any mention of tracking defects or changes. The need to do so is classic CM, but products can and have been developed and delivered without them. It is up to Management to decide whether the risk of not doing these things is too great to take a chance on. For the sake of discussion, let's assume that Management has said that Requirements will be developed in a just-in-time (JIT) manner and that explicit Designs will not be needed. Further, let's assume that defect tracking is needed so that Management can make good scheduling decisions. Depending on who will use the data from the DIET (Defect, Issue and Enhancement Tracking) system and for what purposes, it may or may not be necessary to integrate the VC system with the DIET system. The following are some of the questions that need to be asked and answered to determine this:

Is there any real reason for integration between VC and DIET systems?
Should code changes be blocked unless a valid Defect ID is provided?
What constitutes a "valid" Defect ID?
Should DIET Records be updated with changed file information?
What constitutes the appropriate file information?
Should the integration, if any, be done through an IDE, through a real-time back-end interface, through a periodic batch process or a daemon, or some combination of these?
Should the linkage be unidirectional or bidirectional?
If the VC change records should be updated, what information should they be updated with and how?
Is there any real reason for integration between Build and DIET systems?
Should Defect Records be updated with build information?
Should builds access the DIET system to generate any reports or Change Logs?
Are there any Regulatory Agency requirements that must be met?

Depending on how these questions are answered, CM can pick the "Right Thing" to do and can work with Management, and I do mean with Management, to determine when the "Right Thing" needs to be done.

My father worked for years in a manufacturing plant for aircraft and missiles. One day, for some unknown reason, he was walking around on the floor during a storm and found that the roof was leaking onto some very expensive equipment. There were a few others around, but no one who was authorized to take action (remember the setting). Regardless, he coerced a couple of other men to help him find a giant tarp and stretch it over the equipment, thus saving not only money but the time it would have taken to get the equipment replaced - time that would have meant slipped deadlines and incurred penalty payments. It was not his place to take this action, but it was the Right Thing.

Along those lines, sometimes CM has to step outside of our comfort zone and make pragmatic decisions because they too are the Right Thing. So long as the core CM requirements are met

Happy Father's Day Dad, you are missed.

Ben Weatherall is currently based in Fort Worth, Texas where he practices Practical CM on a daily basis using a combination of CVS and custom tools to support a modified Agile-SCRUM development methodology. He is a member of IEEE, ASEE (Association of Software Engineering Excellence – The SEI’s Dallas based SPIN Affiliate), NTLUG (North Texas Linux Users Group), and PLUG (Phoenix Linux Users Group).

[1] Portions copyright Weatherall, Ltd. 1995 - 2001. Used with permission from the Author and Copyright Holder.

Set as favorite

Bookmark

Email this