Refactoring is an essential element of programming using XP. Typically the source code will be modified until it is optimized with respect to certain criteria, such as minimal number of classes or minimal number of methods. Functionally the system is not change; this is garuanteed by the existing unit tests.
This article highlights a different area for refactoring, namely the structur of a software development organisation.
Sometime problems start, when a second project is started and for this second project an additional XP team is created. Very soon it becomes apparent, that there are functionalities that are common for both projects. Then the question arises, how to organize the teams in order to achieve code sharing.
A first solution might be the common usage of source code. Each team writes the unit tests, it needs for its functionality. A programmer pair of the same team applies the necessary code changes. After integration the functionality is available to both teams.
This approach benefits from a direct communication between the teams. If it is clear upon simple announcement that one team is working on the shared code and also in which part, then most of the administrative overhead is already avoided. Because both teams are using the same code and because both teams are contributing unit tests, generally the quality of the shared functionality will be of better quality.
However, there are also a couple of drawbacks. First there is the question, what should be done in case on of the teams is refactoring the shared code and eventually figures out, that the signature of a certain method should be modified? Should another method with the same name but a different signature simply be added, even if the method is used by only one team? Or should the team that requires the additional method implement a derived class that contains only the additional method? Is this feasable, if components are involved that are implemented using Corba or COM?
Some of the issues can be solved by allowing only a certain set of modifications (by convention, not by management order!). Only incremental additions are allowed such as adding a class or adding a method to the published interface. With "published interface" I mean the set of public methods which can be called from outside the class or component. For these methods unit tests are typically available. Furthermore I assume that no attribute is directly accessible.
But even with this convention not all of the problems are gone. Another problem is: What happens with a method or a class, which is no longer used by any of the teams? Theoretically, these should be removed from the source code. On the other hand, this is not doable as none of the teams can decide on its own, whether the code in question can be safely removed. Therefore the code is left in, resulting in code fragments that are not longer used by anyone. This also contradicts the principle of simple design.
Yet another question must be answered for this approach. XP demands the collective code ownership for the system, and therefore for the source code as well. But who is responsible if there is an overlap in the ownership?
The sharing of source code can also be achieved in a different way, namely by a simple organizational change.
The functionality, which is to be shared, is separated into its own area. For this area at least two engineers, one of each team, will be assigned, who are collectively responsible for the shared code. Let's call this new team the "mini-team". Within its responsibilities it works using the XP methodology.
Different variants of this solution are possible. The mini-team can exist all the time; it could also be that the mini-team exists only temporarily. The mini-team can also be built by people from only one team; however, it is better to have a representative from each team in the mini-team, in order to improve knowledge transfer.
This approach has the following benefits:
Every coin has two sides. This one as well.
What happens, if not only two but, let's say, a dozen teams want to share source code? In this case the "mini"-team is eventually larger than all the other teams!
If actually that many XP teams exists (is there any in the real world?), then the R&D organization is already very large, so that it could well be to treat shared functionality as a dedicated (internal) product. The mini-team develops into a normal XP team. The other teams will become customers and/or users and will be integrated into the decisions of the "mini-team". The underlying principle of the solution remains the same.
In some cases shared functionality is implemented using a framework, depending on software architecture. In general the solution presented in this article works as described. The mini-team is responsible for the framework and might exist temporarily or permanently.
XP in conjunction with changes in the organisation was also the topic of a paper presented by Carsten Jacobi and Bernhard Rumpe at the XP2000 conference. Their paper is available in the conference proceedings in "Extreme Programming Examined"
Carsten and Bernhard compare different reorganisation methods with different software development approaches, among them XP. For the organization of very large projects they propose an approach, which they call "Hierarchical XP".
© Copyright 2001-2002 by Manfred Lange, All rights reserved. Terms of use.
Last change: