Agile Processes in Software Engineering and Extreme Programming

Supporting Agile Reuse Through Extreme Harvesting (p. 28-29)

Oliver Hummel and Colin Atkinson
University of Mannheim, Chair of Software Technology 68159 Mannheim, Germany

Abstract. Agile development and software reuse are both recognized as effective ways of improving time to market and quality in software engineering. However, they have traditionally been viewed as mutually exclusive technologies which are difficult if not impossible to use together. In this paper we show that, far from being incompatible, agile development and software reuse can be made to work together and, in fact, complement each other. The key is to tightly integrate reuse into the test-driven development cycles of agile methods and to use test cases - the agile measure of semantic acceptability - to influence the component search process. In this paper we discuss the issues involved in doing this in association with Extreme Programming, the most widely known agile development method, and Extreme Harvesting, a prototype technique for the test-driven harvesting of components from the Web. When combined in the appropriate way we believe they provide a good foundation for the fledgling concept of agile reuse.

1 Introduction
Agile development and software reuse are both strategies for building software systems more cost effectively. Agile methods do this by shunning activities which do not directly create executable code and by minimizing the risk of user dissatisfaction by means of tight validation cycles. Software reuse does this by simply reducing the amount of new code that has to be written to create a new application. Since they work towards the same goal it is natural to assume that they can easily be used together in everyday development projects. However, this is not the case. To date agile development and systematic software reuse have rarely been attempted in the same project. Moreover, there is very little if any mention of software reuse in the agile development literature, and at the time of writing there is only one published reuse concept whose stated aim is to reinforce agile development. This is the so called "agile reuse" approach of McCarey et. al. [12].

The reason for this lack of integration is the perceived incompatibility of agile approaches and software reuse. Whereas the former explicitly eschews the creation of software documentation, the latter is generally perceived as requiring it. And while agile methods usually regard class operations (i.e. methods) as defining the granularity of development increments, reuse methods typically regard classes as the smallest unit of reuse in object-oriented programming. As a third difference, reuse approaches tend to be more successful the "more" explicit architectural knowledge is reused (as in product line engineering), whereas agile development methods employ as little explicit architecture as possible. At first sight, therefore, there appears to be several fundamentally irreconcilable differences between the two approaches.

McCarey et. al suggest a way of promoting reuse in agile development through socalled "software recommendation" technology. Their "agile reuse" tool, RASCAL [10] is an Eclipse plug-in which uses collaborative and content-based filtering techniques [9] to proactively suggest method invocations to developers. It does this by attempting to cluster Java objects according to the methods they use, just as Amazon, for example, clusters its customers according to the books they buy. The tool monitors method invocations in the class currently under development to predict method calls that are likely to be soon needed and suggests them to the developer. To evaluate their system the authors experimentally predicted invocations of the Java Swing Library in common open source systems and claim precision rates of around 30%.

Although the concept of RASCAL fits well into the agile spirit of providing maximum support for "productive" activities, there is nothing in the technology which ties it specifically to agile development. The approach embodied in RASCAL can just as easily be used with any other development methodology that produces code, including traditional heavyweight processes. Moreover, the approach has the same fundamental weakness as other repository-based approaches – the quality of the recommendations is only as good as the quality of the code repository that is used to search for components. Unfortunately, to date there have been few if any successful attempts to set up and maintain viable component repositories [6]. The version of the tool described in [10] is clearly a prototype, but McCarey et el. do not present a strategy for solving this important problem. Moreover, although RASCAL showed impressive performance for the limited domain of Swing invocations, it is not clear whether this technique will work for other domains with many more classes that have much lower usage frequencies.

1.2 The Core Challenge

The core challenge of agile reuse lies in developing a reuse strategy that complements the principles of agile development and offers a way of promoting reuse in tandem with the key artifacts and practices of agile methods. Whilst proactive recommendation technology such as RASCAL is certainly valuable in complementing such a strategy it does not itself solve the issues mentioned above. In this paper we present an approach which we believe does address these challenges and thus represents a viable basis for the concept of agile reuse. The key idea is to use unit test cases, which in most agile methods should be defined before implementations, to influence the component searching process. Such test-driven development is one of the most fundamental principles of Extreme Programming, the most widely used agile method. Tests are used as the basic measure of a unit’s semantic acceptability. Once a code unit passes the tests defining its required behaviour it is regarded as "satisfactory" for the job in hand.