One method of reducing software development risk is through the reuse of proven code--typically, source code that a developer or team has used before that is formally an asset or trusted when copied and pasted to perform in a stable manner. This is a common practice since there is a lot of duplicate capability from system to system. Krinke’s study looks at this phenomenon and tries to understand whether cloned code complicates software over time. If you are part of a development team and have ever wondered if code cloning is risky, this paper is worth reading.

Krinke presents the approaches of empirical studies that have come before him, and differentiates his approach by leveraging the source code repositories of three open-source projects (ArgoUML, JBoss, and jEdit). Most source code repositories, such as the concurrent versions system (CVS) and Subversion, track changes line by line; the premise is that if cloned code changes less often than noncloned code, it would seem that the changes in the overall system are occurring in the newly authored code. Krinke’s initial findings show that “cloned code is usually older than non-cloned code” and “the cloned code in a file is usually [81 percent] older than the non-cloned code in the same file.” In the projects evaluated, changes over time were not focused on the cloned code and thus it appears to be the more stable overall.

The study’s findings are interesting because it is often thought that introducing new code or code not authored by the acting development team (“not invented here”) introduces risk. This may still be true, but it is not reflected in changes tracked at the code level. There are, however, some challenges with this research. For example, how clone detection is implemented can radically impact what is recorded (false positive or negative). Formatting can often be recorded as a change, but the change itself has no impact on the code itself. The inclusion of test code would likely increase the amount of cloned code detected since it is often auto-generated. More interesting is Krinke’s proposal that developers avoid modifying cloned code when it’s being leveraged. One of the reasons the code was lifted in the first place was because it did something well known to the exploiter. If the developers change it, the trust that it should operate the same way may be compromised. This behavior may affect the results of this study.

For additional details on these issues and reviews of related work be sure to read the whole paper. Otherwise, be on the lookout for a follow-up study that addresses some of the potential shortcomings. As we better understand what happens in practice, more faith and clarity can be brought to bear in future executions.