|Programmers Should Love Change Management Software... Seriously!|
|Programming - Change Management|
|Written by Marty Acks|
|Tuesday, 24 January 2006 19:00|
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.
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.
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.
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?
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.
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.
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.
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.
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.
|Last Updated on Wednesday, 03 October 2007 06:17|