What Am I Supposed to Be Doing?

In many companies, meetings are called frequently to review the same set of open issues and review their status. Long-winded email chains that may get too few or the wrong people involved can add to the confusion. Phone calls or informal, friendly visits from end users may result in the actual problem or requirements being misunderstood by one or both parties. While it may be comforting to just write off communication errors as "not my fault," in the end, no one is happy.

A well-implemented CM tool could get you, the programmer, out of many of these meetings yet still ensure that you're receiving concise information in real time about issues assigned to you. You can receive notifications when priorities and assignments change. You should have less confusion (and fewer disputes) about what was requested, in what order of priority the work should be done, and the exact scope of that work. You should spend more time programming and less time trying to figure out what you should be programming.

Where's the Source Code?

With IT staff coming and going and some folks working at home and in other remote locations, it can be difficult to keep the locations of the current copy of the source code straight. Standards change, naming conventions change, and different applications use different library and source file conventions. Even with good policies and procedures, one "cowboy coder" can muck up the works for the rest.

CM tools ensure that the source is kept in the correct logical place and that code is returned to its rightful location. After a one-time configuration step telling the CM tools about your setup, deploying a change becomes a simple task. You just indicate you are done and let the tool do the rest of the work, which is a set of boring, repetitive, error-prone mechanical tasks that are rightfully beneath you. You'll find it's a great improvement to be able to apply the time you currently spend sweating deployment details on developing better code.

Similar rules apply to new and deleted code. New code should be placed in the correct location. Deleted code should be taken out of your normal production view of the application but still kept available through the CM tool's archives. You spend more time programming while preventing deployment issues created by accidentally misplacing your source code and objects.

Can't PDM Be More Aware of What I'm Doing?

I've always liked Programming Development Manager (PDM) because it's significantly better than the old System/38 programmer's menu we used back in the '80s. PDM's item lists make it easy to work with multiple items at a time. User-defined options let me create custom tasks. The repeat key for options makes me more productive. I could go on and on here.

But a number of things about PDM drive me crazy. For instance, you must constantly jump from one source file to another when working on interactive programs stored using standard source file names. When working on projects in which everyone works in a shared development area, you should be able to know what is clearly "yours." If I'm working on multiple changes at the same time (and who isn't?), I want to easily distinguish between those various sets of source and objects, preferably in a single list. In the age of search engines like Google, I want more robust searching of PDM member and object filters beyond just text searches in the source.

A good CM tool presents you with a user interface that takes the best of PDM and exposes its developer-oriented functionality in a single easy-to-use interface. In addition to eliminating the above-mentioned annoyances, advanced features of the CM tools are logically integrated in this CM-enabled, PDM-like interface. Some examples of these features are "where used" analysis, source differencing and merging, source archive review, controlled promotions, work assignment reviews, and the coordination of simultaneous changes to the same item. When you have this self-contained view of your applications at your fingertips in a single place, you can spend less time jumping from place to place and more time developing great code.

Is There a Simpler Way to Install My Changes?

There's more to the story than just managing and archiving source code: Objects need to be installed properly in order to be of use. Furthermore, the artistry in the source code we write can easily be compromised by screwing up a single step or parameter in the long list of repetitive deployment tasks, thereby impacting the user's impression of both the developer and the entire team or organization. We need to compile these programs so they can be used by end users. Have you compiled all of the objects correctly? Did you specify the correct location for every object? How is data retained and converted when deploying database file changes? What if some objects are in use when you decide to install a large change? Do you have to log in at night to install changes? If a change fails to install correctly, will you be made aware of it immediately?

A CM solution keeps track of the correct way to create the objects and moves them in orderly fashion. This gives you back the time you currently spend sweating these details so that you can do better development and more of it.

What If I Need to Install Changes on Other Servers or Partitions?

This is even more involved than deploying changes on the same server. In addition to the points mentioned above, you have another set of manual tasks and worries. Just for starters, you now have to bundle the objects into a save file, send the objects to the remote system, start another emulator session, sign on to the remote system, and restore the objects.

Ideally, you should simply place an order for a certain set of objects that need to be deployed to a production server (or set of servers). You should select the objects from a simple list or by a group identifier you assigned when you started working on a change—for example, "distribute all objects for project XYZ now that I am done." You should not even have to designate where they go; the CM tool should be aware of their logical destinations based on the application you are working on. The CM tools automate these detailed, boring, repetitive, and therefore error-prone tasks, freeing you to do what you like to do.

Can I Spend Less Time with the Users?

People in your end-user community legitimately need to know when a change is accepted, rejected, underway, being tested, and/or finally implemented. As a programmer, you tend not to be opposed to the users being in the loop (hopefully!), but you would like this to occur with minimal effort in your part.

Your CM solution should allow (and remind) you to make notes about a specific change and separate out comments specific to the users. You should be able to enter these notes when appropriate for you: when starting, when in the midst of, or when completing a change. The users can be notified later at the appropriate time as a change progresses through to the live application. This side effect of CM can reduce and hopefully eventually eliminate calls about status from users and department members, cutting down on the traffic at your desk. This improved communication with the users (which you need to participate in only marginally) can turn visits to the break room into "attaboy" accolades for the new report or feature the users just got instead of those odd stares that seem to be asking "What do you actually do for the company?"

What If I Screwed Up a Change?

Mistakes are hopefully rare, but when they happen, we are expected to jump through hoops to resolve them quickly. Typically, what you need to do right away is place the previous version of a program back into the live system to buy some breathing room while a full correction is formulated. Without a CM tool in place, you have to copy the source or objects out of the live system when you initially implement each change. Then, while moving the old items out and moving the news ones in, you have to check for any dependencies. What if the defect was subtle and you really need, for example, to get the great-grandfather version of something back quickly? That can turn into a little research project of its own.

The archival process is built into the deployment process of a CM tool, so rather than relying on hand-saved archives, you can use a CM tool to easily roll back a single change or set of specific items in a change without worry, whether recent or not, giving you the ability to reliably go back to the way the program worked before the change. CM tools can help to minimize the stress in these situations, turning a potential crisis into a minor blip.

But CM Is Still a Control Tool, Isn't It?

Well, at the end of the day, there is a strong control aspect to CM tools, especially when it comes to the steps taken after the code is written. A well-implemented CM tool does not impact your creative ability to produce great software; it enhances that ability by allowing more time to focus on the task. Other members of your team will be more aware of what you are doing, and managers can use some of this information for measuring team and individual performance. This level of scrutiny raises concerns sometimes that this information will be used for nefarious purposes. In reality, if this happens, your shop may have issues bigger than the presence of a CM tool. A more common outcome of a successful CM tool installation is increased awareness of how much is getting done, improved quality through automation, and the delivery of better and more timely applications to the user community.

In Closing

Certainly CM products do not have a lock (pun intended) on making a programmer's life simpler. Some of the benefits mentioned here can be achieved by using good practices and building some nominal in-house tools. There are also many other types of development tools out there to make your life easier.

Increasingly, CM tools are being viewed less as a programmer tool to be welcomed and more as a manager's tool to be resisted, when in reality CM tools make a developer's job easier and more gratifying. I hope this article has helped derail some of those perceptions. I really believe CM tools should be seen largely as "drudgery reduction" tools for those of us who develop software. If you add up just some of the benefits mentioned above, you will find that equipping IT managers with better information about the development process is a small price to pay to spend more time doing what we like and doing it even better. That's why we got into this industry in the first place...to program computers.

Marty Acks joined MKS in 1998 and plays a strategic role in defining the company's product direction for MKS' iSeries (AS/400) products. Mr. Acks is an authority in the area of change management and software configuration management. Prior to joining MKS, he held a variety of technical and management positions with Professional Computer Resources(PCR) and Pansophic Systems. Mr. Acks co-founded Silvon Software in 1987.