Extreme Reuse Repository

According to JohnLocke, the only true properties of an object are the ideas it has the power to produce in my mind. Thus, a gold nugget produces the ideas of "yellow", "hard", "heavy", etc. According to ExtremeProgramming, as I understand it, the only true properties of a software system are the UnitTests it has the power to run successfully. When someone asks me to upgrade the software, I define the new powers of the system by writing unit tests, and then work the code until it gains the power of running those tests.

However, what if I am working on a single software system within a community working on somewhat similar systems? What if a repository is maintained with many software packages, one of which already has the power to execute one or more of my target unit tests? Would DoTheSimplestThingThatCouldPossiblyWork say that I should inject this package into my own software system, run the new unit tests that come with the package to make sure the new powers took hold, and then refactor the new code so it begins to be accepted by the host system? (The feeling is somewhat like an organ transplant: it's possible that the new package might be "rejected" by the host organism, by breaking too many unit tests, or just being too difficult to refactor in.)

This might not be evocative for anyone else, but I have personally been struggling for several months about the right way to organize, package, and present code within a company code repository. I have the feeling now that all I need to do is define the unit tests each package makes possible, and then give users of the repository some easy navigation to find which existing package meets the unit tests they want. This seems like the path the repository has been wanting to take all along, and it could further spread the idea and gospel of unit tests.

-- DavidSaff

There are some patterns and Wiki pages written about how to go about EvolvingFrameworks. My study group just went over an excellent one by DonRoberts and RalphJohnson. If the goal is reuse then my guess is that a framework will work better than a repository because all the pieces of the framework will already be able to work with each other. I've heard one bit of advice several times: don't build the framework before the projects that are supposed to use it. You really have to do them together, and it's best if you already have some expertise in the domain to start with. While evolving the framework, you put stuff that really does get shared among applications in the framework, and stuff that doesn't get shared into the individual applications, regardless of what your intuition tells you. While refactoring, refactor the applications and the framework together. Writing reusable code is very expensive, so only do it if you really are going to get lots of reuse out of the code. -- PhilGoodwin

I would like to add a principle of ThreeKnownUses? for framework development as well. You need at least three successful systems with rigorous refactoring to your framework and the solutions to get it almost right. However, may be you should never finish refactoring, but there might be great abstractions that remain stable. These belong into a framework.