In today's fast paced development environment, the need for a bulletproof, repeatable process for managing the introduction of change into production is imperative. Release schedules in this environment are no long measured in years or months, but rather weeks and even days. And being able to deploy an error free application on-time, on all required platforms, can often be the single determining factor between success and failure for any organization.
In the face of this new economy, the widespread adoption of standards such as CMM, ISO 9000 and Six Sigma signals the recognition by the development community that there is a solution to the chaos.
To be successful in deploying these standards and best practices, organizations need to look to the software vendor community to provide the tools and solutions that will allow them to integrate their business process into the development lifecycle.
In this discussion, we will focus on tools and solutions that integrate into the development environment and allow us to design a repeatable process for managing change. Saving Changes...
Sort By:
Sunil SharmaCEO| Cerebral Works Inc.Herndon, Va, United States
A danger of integrating tools and solutions into the development environment to design a repeatable process for managing change is that such initiative may take a life of its own and managing it becomes a full-time project. One of my clients while dabbling with SCM tools and vendors realized this and now it has gone back to version control software like PVCS.
How do you counter such an argument against using SCM tools that is partly based upon experience and partly on perception? Saving Changes...
Anonymous
Whether the initiative of integrating SCM tools into the development environment and possibly taking a life of its own is a danger, as Sunil perceives it, or not, really depends on the criticality of the problems that are to be solved by this type of integration.
If this integration effort solves production problems (such as controlled releases, being able to fix what actually needs to be fixed, matching source and executables, clean as opposed to wild parallel/overlapping development efforts) for the resolution of which valuable resource time were spent in the past, then even if this effort takes a life on its own, I would argue it is justified. In the worst case, the resources are shifted from solving problems by continuous fire fighting to solving them by more structured approaches such as SCM tools, and SCM integrating with development environments and builds. My experience has been however that this shift, even if it takes a life on its own, provides much more than simply resource allocation:
First, in most of the cases the resources spent on integrating and maintaining SCM are much less than those spent on fighting fires, which often is a very ad hoc type of effort.
When such an effort takes a life on its own this means that a team is formed that is tackling such problems company wide. This means that while prior to these efforts things were done independently by different application teams, now there is an effort that tackles these issues in a wider scope. This has a couple of desirable side-effects,
(i) it forces knowledge transfer (ii) knowledge transfer to an independent, possibly not-as-technical party means simplification of existing methods (such as builds, releases and maintenance etc.), this inevitably requires standardization of methods and practices, since one team cannot inherit and solve the problems of all application teams each in its own way (so this must go beyond resource allocation as outlined above) and (iii) it improves communications between different application teams that have dependencies on each others code/modules.
Clearly, this type of shift requires effort, management buy-in, a lot of communications with the application teams themselves (that will almost always be reluctant to hand over some of their efforts, because of potential impact on them), but in a time where software development, maintenance and deployment has become so much more complex, can we afford not to do this?
I have to agree with Patrick and Muhittin on this topic. After working with many clients who stuck with versioning tools as well as those clients who adopted full SCM tools, the benefit of the complete SCM tools far outweighs the effort required to implement and maintain such a system.
Time after time those sites that have chosen tools such as Source Safe, PVCS, etc. spend a significant amount of time trying to track down problems with their life cycle rather than creating a better software product. These problems are usually very visible since they appear at the QA and Production stages of the life cycle where the users and management are very aware of problems.
By committing the resources and effort to implement an SCM tool that will model their full Life Cycle Methodology and provide the required training the benefits of improved communications, reporting, defect tracking and build management become evident very quickly.
Implementing a full SCM tool requires change to the organization (a different kind of change) that can be very difficult for the developers and technical leads to buy into. If management has the commitment, however, this process can be implemented very successfully. Saving Changes...
While I agree SCM is about repetition, I still think it deals with continuous improvement and for that uniqueness must exist alongside. Saving Changes...
"In the real world, the right thing never happens in the right place and the right time. It is the job of journalists and historians to make it appear that it has."
