You are here

A Primer on Reuse - Reuse Practices

Author(s): 
Mark Chung and Chris DiGiano

The software engineering literature identifies many kinds of reuse [Leach, 1997], but for our purposes we will focus on three kinds:

  1. Application reuse (you as product vendor to teachers): A teacher may want to reuse your mathlet by customizing the text or tweaking the behavior to produce an alternate lesson. Similarly, a content provider may want to integrate your mathlet into an online assessment or class. You can't anticipate all the possible uses for your mathlet, so it makes sense to build in enough flexibility to accommodate a reasonable range of uses. We will call this kind of reuse application reuse.

     

  2. Designing for reuse (you as producer of code for developers): A third party developer may want to reuse your mathlet by using it or its associated library to develop another mathlet. It wasn't surprising to us to see that the first mathlets featured in JOMA almost all had graphers and that they each used their own implementation. By designing for reuse, you make it easier to reuse your own code, and if you decide to release your source code or binaries, you increase the likelihood of adoption by other developers. This could eventually lead to improved software quality and longevity, because those developers may provide feedback and patches [Raymond, 1999].

     

  3. Code reuse (you as consumer of code from developers): You may want to reuse existing code to speed up your development. This avoids duplication of effort and, if you use an established library, may increase reliability and reduce debugging.

These reuse practices are summarized in the following table:

The provider The product The receiver (reuser)
Application Reuse you, the product vendor application (mathlet) teachers
Designing for Reuse you, the producer component or source code developers
Code reuse developers component or source code you, the consumer

Given all those benefits, why doesn't everyone engage in reuse? First, designing for reuse costs more than not designing for reuse, because it takes more effort to design and develop code that works outside of a specific application and to create associated documentation and tests. However, much of this effort should be considered good programming style, and the effort will pay off when you reuse your own code. Second, the code may be a trivial implementation or a toy example in which designing for reuse would consume most of the coding effort.

There are also some issues when reusing code. First, the code you may want to reuse may have a licensing policy you disagree with or may be prohibitively expensive. Second, it takes effort to find suitable code to reuse, select when there is more than one candidate, and understand the code. Third, there's the educational value of coding it yourself. You may not want to reuse code if you're teaching yourself to program. However, most professional programmers today reuse code whenever they can.

Mark Chung and Chris DiGiano, "A Primer on Reuse - Reuse Practices," Convergence (December 2004)