When the United States landed a man on the moon, my wife and I use to engage our friends in fun debates on whether Neil Armstrong really stepped onto the surface of the moon or did he descend onto a huge sound stage just north of Phoenix, AZ. As farfetched as that argument is, in many cases, upper management in many software development organizations are being led to believe that their Eagle has landed at Tranquillity Base when it fact their project is “Lost in Space.” Much of that information is coming from the Configuration Management System (CMS).
The CMS has the job of retaining all essential project information: requirements, design, code, test plans, test data, test results, review reports, project management information, architectural data, and user documentation. It is designed to prevent physical destruction of information such as altering of reports; unrecorded changes to requirements, code, or tracking data; unauthorized entries in data fields; or physical failure of media. Without a functioning CMS, management cannot rely on the accuracy of any information. However, the CMS continues to be undermined in numerous ways that lead to the destruction of the information infrastructure.
We continue to destroy the CMS by passive behavior. We claim critical success that an organization doesn’t object directly to the having a software configuration system, but do very little when they fail to use it or fail to use it correctly. Consider the bug-tracking database, which is part of the CMS. It is supposed to report each error found in testing. Those errors are suppose to remain open until the error is tracked down and repaired. Successful managers rely on statistics from the bug-tracking database to monitor project progress and decide about product release. Such statistical information, however, loses its usefulness if errors and their handling are reported accurately, but passive corruption of this database takes place such as these many forms:
- Developers remove error reports claiming that they are not really errors, giving specious reasons like “that particular build wasn’t done correctly,” which is another interesting fact in and of itself.
- Managers remove error reports claiming, “We are not supposed to be testing that yet,” which gives their managers an overly optimistic sense of progress.
- Testers file incomplete error reports, omitting such valuable information as the original cause of an error, which would help management detect those areas that need additional support or training.
My biggest gripe however is the perversion of the CMS’s value of making information available to all who might need it, while protecting information from corruption by those who have no authority to change it. We have taken the CMS’s ability to restrict access and applied it to restricting the reading of the information. Doing so, the whole purpose of the CMS is undermined.
I contend you never know who needs to know what. For a development organization to be successful, information must flow freely. But managers become territorial and say that certain data “is relevant to their group only.” Maintaining morale and keeping a blameless atmosphere are laudable goals, but if these goals can be reached only by dismantling the information infrastructure, the project is a lost cause.
How do we get out of this mess? First of all, understand that the CMS is not just some technician’s tool, but a management tool that underlies all communication and control. It belongs to you so manage it, which means the CMS group should report to upper management, not to project management. Second, set and enforce a policy of complete and open information at all times and resist plausible sounding arguments for hiding information that is in the CMS. Third, manage your people without competition because competition leads to the desire to hide information from management.
