Let's face it: Quite often, IT organizations can be as resistant to change as the users we sometimes love to hate. I'm sure we've all experienced times when a developer discovers a new technology and utilizes that technology "on an island." Then that developer leaves the company, and the organization finds that no one else understands things that this developer created. Two problems are created by this situation: It's highly likely that the applications developed by this barn-storming developer will eventually fall by the wayside, while at the same time, other developers in the organization are not able to take advantage of what may be more advanced techniques. "Super" Programmer Every company has one, a developer who likes to stay on the cutting edge, utilizing the latest, greatest techniques and technologies. Maybe you're a strict RPG shop, but suddenly one developer learns Java and begins to create classes for his projects. While it's great to utilize Java, if he's the only one who understands this technology, he's also the only person who can support these APIs. The real problem is that if this developer leaves the company, no one else can support anything that he was responsible for. It's quite likely that whatever he developed will need to be scrapped or completely re-written should any changes be needed. While the easy solution would be to squelch this kind of developer through the implementation of strict programming standards, that solution may backfire in that good, creative developers will take their talents elsewhere.
Here are some suggestions for managing the introduction of new technologies in such a way as to prevent problems down the road. "Flexible" Programming Standards If your organization doesn't have a set of standards that each developer is required to follow, you're asking for trouble. Having standards in place for how code is developed and modified as well as definitions for what technologies are to be utilized gives each developer a guideline to work with. Developing a set of rules, however, is only part of the equation. Review and update these standards periodically to keep things current. This allows the introduction of new technologies to be managed in such a way as to avoid too much "bleeding" from the cutting edge. Allow everyone on your development staff to have input on changes to these standards. That way, you can manage the introduction of new technologies, while allowing everyone to be aware that these changes have been implemented. This also gives your entire development staff some say in how things are done, which can help with their overall job satisfaction by giving them some "ownership" in the development process.
Let's assume, for example, that the bulk of the code running on your system is written in RPG III. In an effort to update this code, you might implement a standard that dictates that any programs that require more than 25 percent of the code to be changed must be updated to free-format and that all new applications should be developed in free-format, while all code changes of less than 25 percent of the source can be done using the existing RPG version. This allows your programming staff to ease into a new technology.
In addition to programming standards, good documentation standards can also help to prevent the growing pains that can be caused by change. For example, requiring all developers to use a specific standard for notating code changes gives a good clear definition of the purpose of a code change and allows future developers to have some insight into what the developer was hoping to accomplish and why the code change was done. Clearly defined documentation standards can help to set the expectations for the developer ahead of time.
Top IT management must support strategies for adopting new technologies, and standards committees are a great way to ensure that management support is in place from the start. Technology Roundtables While your development staff may have more hours scheduled on projects than there are hours in the day, allowing them to devote time to technology roundtable discussions can reap great benefits. Weekly, bi-weekly, or monthly discussions among developers can help the old-timers keep up with the trailblazers, at the same time allowing open discussion among developers over concerns they may have about the introduction of new technologies. This can reduce the fears of change, while helping to prevent the introduction of truly risky technologies.
Half the challenge here may be getting people to come to the table, so you'll want to ensure you do everything you can to encourage participation. Making participation mandatory is one way to go, but you might also want to consider making it a "free lunch" meeting. I haven't met a programmer yet who would turn down a free lunch (myself included). You also might consider the "word a day" calendar approach, asking each participating developer to bring one new concept to the table at each roundtable meeting. This encourages developers to explore what's out there and share that information with the group. Education One great way to help encourage change is to spread education among your entire development staff. Requiring that your developers keep their skills up-to-date can greatly increase their ability to manage change. To ensure that your developers are getting all the information they need, encourage (or require) them to attend educational conferences at least every two years. The wealth of knowledge available at conferences like COMMON can't be measured in dollars. I think you'll find that developers will come back from this type of event with a renewed excitement about what they do. It's also a good idea to have attendees document what they've learned and distribute it among the rest of the development staff. This allows you to "share the wealth" and get the most out of the educational dollars.
It's also a great idea to create an internal "techie" newsletter or blog and ask each of your developers to contribute an article on a regular basis. This encourages developers to keep their skills up-to-date, while also creating a forum through which new ideas can be shared.
The Web site you're reading right now is another great source for obtaining and sharing information about new technology. Encourage your peers to subscribe to and read newsletters like those published by MC Press. Resistance Is Futile Instigating change also means encouraging those who are most resistant to change to accept and even initiate change. In some cases, this can be difficult because you are dealing with differences in personality. When trying to combat resistance to change, a picture is worth a thousand words. Demonstrating what can be attained by implementing new technology is often the best way to bring forth acceptance of the most resistant developers. This not only helps to convince others of the value of a new technology, but can also help to avoid the introduction of new technology just because it's new—without regard to whether or not it adds value.
For example, while the desire to convert existing RPG applications to Java may sound enticing to an ambitious developer, that developer must make a good business case for why this should be done. Introducing new technology just for technology's sake just doesn't make sense. If, on the other hand, a specific requirement could be accomplished more efficiently by converting an application to Java, then it would be much easier to make the case for converting that application to Java. An example might be an application that needs to read or write to a Microsoft Excel spreadsheet. Open-source Java classes like those developed as part of the Jakarta POI project give a developer the ability to do this, so the argument can be made that without introduction of this technology, the required task can't be accomplished. Change Is the Only Constant There is a delicate balance between encouraging the adoption of new technology and preventing the negative impact that can be caused by "bleeding-edge" technology. Finding ways to deal with this can be a challenge, but I hope this article has given you some ideas for some positive processes to implement to help make that change a little less painful.
Mike Faust is the Applications Support Manager for Invivo Corp in Orlando, Florida. Mike is also the author of the books The iSeries and AS/400 Programmer's Guide to Cool Things and Active Server Pages Primer and SQL Built-in Functions and Stored Procedures. You can contact Mike at mikeffaust@yahoo.com.
|
