The term “glue code” is a colloquial term for “a thin layer of software that connects software”. In general, it is used to connect to software components that were not designed to interact with each other. This is a common problem and, when sensibly done, is a fine approach. However, it is possible to develop “super glue” solutions which are, in the end, fragile and difficult to maintain.
“Standard glue”
The
following are examples of standard “glue code” functions. Correctly implemented they are a thin layer between modules
- Data format translations: repackaging data between two different formats, such as an XML to CSV translation function.
- Communication port: adding a data transmission function between two pieces of code.
- Registry/read functions: these are functions that map data from one source (such as requirements) onto an object (such as a model)
- Error catching: these functions, generally, work in concert with other glue code ensuring that the data exchanged between the modules is correctly formatted.
Crazy glue
How 
do I tell if I have crazy glue? There are 4 basic warning signs
- Use of multiple languages: connecting two software components written in different languages is a common task. However, if you find your glue code uses more than one language chances are you doing something to convoluted.
- Use of files for the interface: ideally glue code is written by leveraging existing APIs in the software components. If the function interface is through a file and a “poling function” the data exchange will be difficult to maintain.
- The growth of “special cases”: when the number of special cases the glue code has to handle gets above 10 to 15 chances are the data exchange format is not well defined.
- Size: there is no hard and fast rule for how large glue code can be, however at some point in time it stops being glue and becomes its own software component.
What to do with crazy glue?
In the ideal world, the glue code would be replaced with improved APIs in the source software components. Often this is not possible due to ownership issues. When this is the case basic software best practice come into play
- Break the glue into components
- Look for ways for one component to encapsulate the other
- Refactor the code to remove special cases
- Consider using different software components
