SCM Benefit Analysis Document

Table of Contents

• Purpose
• Benefits of Software Configuration Management
• The Ghosts of Development Past

Purpose

[Back to Top]

Benefits of Software Configuration Management

Managing any corporate project can be difficult. Corporate software development projects are no exception. The number of people involved, including end-users, business analysts, developers, testers, trainers, documenters, system administrators, and managers, the different requirements and agendas of each group, the development tools involved, the number of components that comprise an application, turnover in project staff, and the on-going nature of maintaining an application, can present many obstacles to success. Organizing and managing the development effort via a robust SCM system provides many benefits that can help to eliminate potential stumbling blocks.

• Reduced downtime. Any time an application fails, the impact can be significant. End-users are impacted as their ability to do their job suffers. Developers suffer as they must interrupt whatever they are doing to research and solve the problem. System administrators may likewise be impacted as the problem may be installation or environment related. The corporation suffers not only from the lost productivity associated with the newly directed efforts of the end-users, developers, and system administrators, but from the opportunity cost of lost revenue that the application would have generated. Indeed, if the failed application is "mission critical", the consequences can be catastrophic. In any case, the longer the problem persists, the more unpleasant the financial situation becomes.
  

  SCM addresses this problem in a variety of ways. Obviously, SCM can't prevent a production application from failing if the application is truly defective. Oftentimes, however, applications fail because one or more of the components in a run-time environment are out of synch with the other components, in the wrong location, or missing entirely. These types of problems - especially out of synch components - can be extremely difficult and time consuming to resolve. A release-centric SCM system that provides version control, build control, and distribution control features can virtually eliminate this problem.

  If, on the other hand, the problem does lie in the application itself, SCM reduces down time by providing easy identification of the currently installed production release, allowing for all project components to be easily retrieved for research and development purposes. Should the development staff determine that fixing the current release would require an inordinate amount of time, the SCM system would allow them to easily "roll back" to any previous release.

• Increased efficiency. Ultimately, all the benefits of SCM result in increasing efficiency throughout the development process. The previous discussion regarding the ability of SCM to reduce application downtime is really the result of increasing efficiencies. The four areas of SCM - version control, build control, distribution control, and bug tracking - combine to provide increased efficiencies throughout the software development process.

• Version control. In group development environments, it is not uncommon to encounter source code conflicts, whereby two developers wish to make changes to a single source module at the same time. In environments practicing no SCM, each developer may obtain a copy of the current source module and begin making their changes. The first developer to complete their modifications and save the file, or move it to the "global" location where source code is kept, will lose their changes, however, once the other developer does the same. At best, this situation is discovered early on, when the first developer's changes are still fresh in their mind, and can be recreated. If really fortunate, there may even be a backup copy laying around - allowing the two versions to be painstakingly merged together. Generally, however, these types of situations are detected much later - usually in testing, but oftentimes - especially in development groups not practicing SCM - not until the application is in production. When this occurs, the modifications that were previously lost must be recreated, this time without the benefit of recent memory or backup copies.
  

  Version control eliminates this problem via sophisticated locking and messaging schemes. For example, attempting to retrieve a source module previously retrieved for modification by someone else will result in a message indicating that the module is locked by another developer, and changes are not allowed.
  
  

• Build control. Very much reliant on version control and its associated release mechanisms, build control ensures that project components are built in a consistent, automated, repeatable fashion. In an environment with no build control, project builds often consist of a variety of manual processes, building components individually. This is an extremely error prone approach that can lead to problems in the future. Say, for example, that we have a project consisting of 2000 source modules, and modules 57, 202, 203, 302, 721, 909, 1104, 1411, and 1836 need to be rebuilt for the new release, and despite the best intentions of the individual doing the build, module 203 fails to get rebuilt. It's bad enough that we have now created an unnecessary problem that will have to be dealt with in the future, but it can be an extremely difficult problem to diagnose, as the "correct" source code will exist in the environment where the "incorrect" behavior is occurring. SCM eliminates such a problem via a release-centric, automated build process, which not only allows for easy extraction of a pre-existing release, but also provides the ability to accurately recreate a release at any time.
  

  From a productivity standpoint, a quality build-control process will decrease the time required for the edit-compile-debug loop, thus making all the developers working on a project significantly more efficient.
  
  

• Distribution Control. Distributing the components of an application to create a viable run-time environment is important to development, testing, and production control. Improper distribution of an application can result in run-time problems that are extremely difficult to diagnose, as explained in the previous discussion regarding application downtime. Distribution control, accurately maintaining the relationships between installed runtime components, coupled with a release-centric SCM system, eliminates this problem.

• Change tracking. Correct management and tracking of application defects allows development to respond to and correct problems in a more timely and effective manner, helping the development group to produce more stable applications, reduce downtime, and gain credibility throughout the corporation. Properly implemented bug tracking ensures an association between a change and the code that was modified to fix it, providing a valuable repository of information, and allowing for quick and easy answers to the following questions:
  

  What code did we change to fix a specific defect?
  What defect was fixed by a specific code change?
  
  

• Increased security. Oftentimes in corporate organizations devoid of SCM, developers are granted complete access not only to development environments, but to testing and production environments as well. With this type of access available, even the most diligent of developers will work directly in the testing or production environments on occasion. This can lead to a multitude of problems including out of synch source code within a release, crashing a production application, or corrupting production data. The last of these - corrupt production data - can be extremely problematic, as the application accessing the data - or in client-server environments, the many applications - will be adversely affected, possibly unable to run at all. SCM eliminates this problem by ensuring that any software release - the one currently in production, the one currently in testing, etc. - is wholly contained within the version control system, easily identifiable and retrievable to an isolated environment. Thus direct developer access to testing and production environments can be eliminated, forcing all releases through the version control system, ensuring increased control and stability of the testing and production environments.

  Even more important than protecting the testing and production environments, proper SCM implementation also provides increased security to the development environment by controlling access to a project's source code files. These files represent the corporation's ever-growing investment in its software assets, and must be protected from accidental or malicious destruction.

The Ghosts of Development Past

• A product that has been under development is ready for release to Systems Test. Normally this is a simple manner of moving the code to a staging area and then having the Change Management team move the code to systems test. Unfortunately, this staging process takes 4 or 5 attempts because pieces of the application are missing.
  

  How this would have been prevented with proper SCM... Since the SCM system would contain all the code that was ever worked on for the project, moving the code to systems test would require no more than releasing the project and creating a copy in the new location.
  
  

• An updated release of an application has just been released to test. Unfortunately, this release contains a never before seen defect. Also, this application contains several executables derived from hundreds of separate modules. The developer assigned to fix this new defect has to look at most every file to determine what changed and where the bug was introduced. It was discovered that a single file was omitted because of a missed, undocumented manual step oversight.
  

  How could proper SCM assisted in this problem... The SCM system would be able to identify the files that have changes in between every release of the application. This would have given the developer a much smaller subset of files to search for the error. In this case, the SCM system contains ALL the files required for a release, so no manual steps are included when creating releases.
  
  

• The person with on-call responsibilities gets a page. After looking into the problem, the on-call person determines that the error really exists in another system. Unfortunately the on-call person can't access the other system and must page someone else to look into the problem. This causes an extra delay and reports that were needed in the morning are now late.
  

  How this would have been prevented with proper SCM... The SCM system would contain all the source and executables for all systems in a common location. The on-call person could have simply copied down the correct system and fixed the problem.
  
  

• A development team is ready to move an application over to systems test, however the team cannot find the source that was used to build an executable that has been used for several weeks. Apparently the source for the application was deleted accidentally with some old test code.
  

  How would this been prevented with proper SCM... The source code repository would contain all the code that was developed during the project, even test code. Once a file is placed under version control it is always available even if it no longer belongs to a release.
  
  

• A developer is assigned the task of adding a new feature to an application. Fortunately, another application has already implemented a very similar feature. Unfortunately, the developer never knew about the other application or the existence of the feature because it exists on another developers machine. The developer successfully implements the feature, but recreates code that already exists within the organization.
  

  How this would have been prevented with proper SCM... The SCM system is implemented so that all projects are accessible in a central repository. The developer could have researched the other projects, found the needed code, and saved a lot of time by reusing the existing implementation.
  
  

• A project is ready to move into production, so the development team moves the code into the correct staging area. After the Change Management team installs the code in the production environment, a previously fixed bug reappears. Apparently, an old copy of one of the source code files was accidentally moved into the staging area.
  

  How could this been prevented with proper SCM... The correct use of the release mechanisms within a SCM system would have prevented an old copy of the source and/or targets to be released. Only the current copies of the source code would have been released from the source code repository.
  
  

• A project is nearing a major milestone and management needed to make a decision on allocating production resources to the effort. Unfortunately, the management team had no easy way to determine the status of the project.
  

  How this would have been prevented with proper SCM... The SCM system would collect and generate metrics in an automatic fashion. These reports could be used to track the progress of the project. Having the SCM system automatically generate metrics can keep a development effort from "Going-Dark." In addition to the reporting, a proper SCM system will encourage periodic builds, allowing anyone to quickly test the status of the application.
  
  

• Two developers simultaneously modified the same source code file. When the second developer installed their changes, the first developer's changes were overwritten.
  

  How this would have been prevented with proper SCM... The locking and messaging features of proper version control, would have ensured that the developers were unable to unknowingly make simultaneous modifications to a single source file.