Does the title of this article seem absurd? In the past few years, change management (CM) software (a.k.a. change control, software configuration management, and more recently, application life management) has been somewhat co-opted by IT managers. CM is seen by many as a solution to strengthen IT controls in order to pass audits and comply with Sarbanes-Oxley requirements. Don't worry; this is not another Sarbanes-Oxley article. It's actually just the opposite. While the benefits of using CM tools are real, what excites me is that these tools are really all about allowing programmers more time to program. This article looks at the value of CM tools from a programmer's perspective.
First, a brief background is in order. I am one of those 40-somethings in our industry who cut their teeth on the System/34 and System/38 before landing on the AS/400, now relabeled the eServer iSeries. I had a brief stint on the S/3 but somehow missed the S/36. Go figure. I guess that S/3 experience puts me in the late 40-something crowd. Now, I seem to do a little less programming every year. Some of my peers see that as a good thing.
Ever since getting into computers, I have always been curious about how to do things more quickly. If an assignment took an hour, I would look for a way to do it in a half hour. I'd then take that half-hour task and see if I could do it in 15 minutes, and so on. Perhaps I like to work better and faster, or perhaps I'm just lazy. It can be a fine line. Nonetheless, after developing application software products in the early half of the 1980s, my interests turned toward developing tools that make life easier for myself as a programmer (and to make life easier for other programmers, which I suppose has ensured my continued employment).
In the interest of full disclosure, my day job is working for a software vendor. You can see which company at the end of this article. As such, I am hardwired to see how cool CM and other tools are for programmers.
Change management tools are often purchased by IT managers with varying responsibilities. This is a good thing: The right tool can make them more effective in their jobs. After all, these folks need to justify their budgets: What are they spending and why? But in some ways, it seems a shame that the value of CM tools is seen as largely managerial in nature. My programmer's background tells me a predominant benefit is that CM tools let programmers code more quickly, more accurately, and with fewer interruptions.
So why should programmers love CM tools? Let me address this by answering some questions that come up in the day of a life of a programmer.
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.
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online