How to Prevent Problems When Recycling IT Code

[Former Member]

Reusing code saves programming time, coder labor, and often project time. Yet, code reuse can introduce new problems along the way or propagate inefficiencies. Fortunately, there are several ways to prevent problems from arising when recycling IT code.

 

1. Test your primary code modules before putting them in the code library. The old joke that computers let you make the same mistakes a hundred times faster becomes reality when flawed code modules are distributed to dozens of coders or several software projects at once.

 

2. Work on improving current code library sections when the workload is light. Debug known problems and verify that these improved code modules work with related applications. You can then maximize the productivity of both programmers on staff today and the code library's effectiveness in the future.

 

3. When there is a bug or potential conflict in a code module, put that in the metadata or reference files for the code module. Let programmers or project managers know the possible risks of using that code module. If they cannot take that risk or are trying to decide which IT project code to use, the warning in advance can lead them to make a better selection for their own project.

 

4. Know what the code is intended to do. Then, capture that information in the related documentation. Is it intended to check a specific cell reference or data value? Is the module intended to convert values? Identify the code module's intent so that it isn't used incorrectly. If future users see a different result when recycling that code, they will then know that something is wrong.

 

5. List the dependencies that allow that code module to work. It simplifies troubleshooting when code doesn't work as expected. If it needs Java, say so. If it requires input from several specific fields or only accepts values for those fields, include that in the code library's entries. Recycling IT code is only effective if it can be used as is or with minimal changes.

 

6. Describe the operating systems, supporting processes and running applications the code was created and worked well with. If someone must create a new software version using the existing code library modules, noting changes in this computing architecture will allow them to update the code as it is changed.

 

7. Maintain configuration control. Don't allow someone to put untested or unverified code into the library for use by others. Limit the authority to delete so that someone doesn't accidentally erase good code while removing a mistaken upload to the code library. Restrict the ability to upload code to an identified individual so that malicious software cannot be introduced to the code library.

 

Reusing code can be a boon or a nightmare to a project depending on the preventative measures put into place. Following the above suggestions will ensure that mistakes are not introduced along the way when reusing code. Above all else, be sure that there is open communication about the code in order to maintain its original integrity.