CM Problems in a Complex Technology Environment


conducted classes on the new methodology to the entire project group and senior managers off-site so their full attention was maintained. Extensive studies were conducted within the SCM group to determine why builds took so long and why so many of those builds broke. The results were interesting to say the least. Developers were checking in untested code, which meant that there were no peer reviews being held, little-to-no supervision, and a significant amount of gold-bricking done because user expectations were not very clear. Requirements changed faster than developers could consume pizza, and those changes were not communicated throughout the development group. Developers did not always check in their code before leaving for home each night. Parallel development was not allowed. Branching was done late in the development game and just before a required build. The Product Manager wanted change control only after a successful build had been performed, which meant that baselines were nebulous at best.

The change control process was developed in flow chart format first, so I could walk everyone through the process and get approval or sign off. Once the change control process was in effect, things got a little slower, but builds improved. That is, they became more successful – not faster. I suppose the reason was that people became more conscious of their work effort and products before promoting code to SCM.

In spite of all this, the problem’s roots were not in the workflow processes, although some needed significant improvement, but in the technology. The SCM solution and the J2EE application server were at odds. Mostly, there were serious formatting issues and the SCM group had to reconcile (reformat) the code in order to complete the builds. This went on for several months before someone finally wrote some scripts that automated the reformatting process. There are a lot of things that could have or even should have been done before things got real bad and frustrating for the development group – but they didn’t and work products suffered as a result. Millions of dollars were wasted on unnecessary contractual support that could have been solved by better internal and external communications, and a better understanding and appreciation of the values that can SCM bring to any software project.

The major lesson learned in this scenario, was that all the money in the world cannot fix an ineffective process if people don’t work together as a real team. Looking at things retrospectively, SCM planning was never completed. Come to think of it, project planning was non-existent. Someone at the executive level should have done a little more homework and perhaps listened a little more carefully to what their staff recommended. Clearly, not a very good set of circumstances for any CM manager or release manager, but opportunities to excel abound!

Dick Carlson is the founder of Software Engineering Solutions, a training and mentoring consulting firm. Dick has 20+ years of software engineering experience that focused on training and mentoring, development and implementation of software lifecycle methodologies, software configuration management, software quality assurance, and software process improvement. Dick has trained and mentored teams and individuals on efficient SCM activities, project management, requirements development and management, risk management, business modeling, and business re-engineering. He has also been involved in software process improvement initiatives in preparing organizations for SEI CMM Levels 2 and 3 compliance. 
Dick can be reached by email at
[email protected] 

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.