Consistent tracking of source code changes and system objects is one of the biggest challenges facing application developers. We are all familiar with situations in which source code is missing or there is no record of which version of a program is the most recent. The best solution to these problems is to implement some form of change management procedure. To make it work, however, there must be political support from management.
Before you can hope to adequately control software changes, your company should make the decision to invest in a software tool. Third-party packages can run thousands of dollars to purchase and support, plus they present a significant learning curve. The upside is that you will be using a slick, full-feature system without the responsibility of maintenance or technical support. Conversely, a custom system requires many billable hours to implement but can be built around your business rules. Either approach offers part of a solution to your source management issues, but this may still be a hard sell to people who have never plowed through libraries, looking for elusive source members.
It would be helpful to study the effects of not having a change management system in place. Also, find some quantitative method for demonstrating the ROI on such a purchase or endeavor. Calculate the value of the time wasted searching for code as well as the time involved in false starts and general development. Show a scenario of downtime caused by not having a proper tracking mechanism in place.
Management plays an important role in the software development environment. It is generally not a managers job to write code. Rather, managers should help control the development flow. No matter how flawless your procedure is, your efforts are wasted if your management fails to get with the program. Frequently, the argument you will get is that change management rules must sometimes be abandoned since emergency production issues arise and there isnt time to run those application changes through the change management process. The belief is that somebody needs to be able to make emergency changes outside the safety of the change tracking, but this argument is invalid. Changing source and moving new objects to production is a function of minutes and nothing more.
There are few situationsif anyin which circumventing change management procedures should be tolerated. More than likely, the exception is encouraged by someone reluctant to lose the system-level authority he or she probably should not have anyway. This is a common experience among AS/400 programmers. In speaking with recruiters, I have found that a prevalent problem in hiring is that many candidates come from what one
termed fly-by-the-seat-of-your-pants AS/400 environments. It is often difficult to find a programmer who understands a structured methodology.
Many supervisors who have been programmers forget that the farther up the ladder they move, the less technical their job becomes. Demands of the higher position dictate that they lead the technical work, not perform it. They are, however, in a good position to aid with the implementation of a structured environment.
There must be a written procedure for programmers and an incentive to adhere to it. Policies must be followed so everyone works under the same system. Most of all, management must play its role and embrace a development environment that includes change tracking and documented implementation. Without management support and cooperation, any reasonable attempt to get a handle on your software development is very likely doomed. This is a training issue. Companies rarely define the role of the manager well; they simply promote from the ranks. This creates a two-fold problem: It removes the manager from the day-to-day exposure that helps keep their skills sharp and places an underdeveloped supervisor in a position to help or hinder the development process.
The lesson is simple: Companies that understand the need for a controlled development model will not suffer the frustrations of a sloppy product.