I'm working on my monthly column for Software Test & Performance magazine, and I'd like your input.

Agile and extreme programming methodologies are based on code re-use. That makes plenty of sense, but it assumes that you can find what you need... even if you aren't looking for it. After all, most of us have at least three cordless screwdrivers, because you never know where you left it the last time. It's faster and cheaper to buy a replacement than to putter around, searching for the screwdriver in the garage and getting distracted by other things ("Wow, I forgot I even owned a basketball"). And that doesn't count the search for the charger.

Does your software development work the same way?

If Agile and Extreme Programming are all about code re-use, then how do you get your SCM tools (or any other tool) to advertise the existence of code that might be available for reusing? That is, it's one thing if you remember, "Hey, I worked on something similar, 3 projects back; let's search through that code to see if any of it will save us time."

But what if your memory is poor, or you're new to the team? How do you find out about the code you didn't remember? Isn't that how teams re-invent the wheel (and have to debug the wheel), or wind up with 5 modules that do the same thing?

I'd like to hear about the ways you organize your software garage... er, that is, your SCM tools... so that you can both find what you KNEW you had around here somewhere (i.e. search for code you remember writing in a previous project) and also get some sort of "Hey! I can do this for you!" advertisement from your personal or corporate stash of existing work?

From my initial conversations with developers, I suspect that the answer to the first part (searching for an answer you KNOW exists) is much easier than the second (code advertising its existence or suitability to the present need). If that's so, what's the result? Despite best intentions, do you write new code (that is, buy a new cordless screwdriver)? Do you build or wish for or buy tools that claim to solve the second issue, in addition to the first?

I have to hand in my article by the end of next week, so it'd be great if you could share your opinion with me (publicly, here, or by private e-mail to [email protected]) before June 15th. Please be sure to let me know how I can refer to you in the article ("Joe Jones, a programmer at FooBar Corporation in Orlando, Florida"), or if we have to find another way to cite your input ("Joe Jones, a programer at a financial services company in the southeast U.S.").

Esther Schindler
contributing editor, Software Test & Performance magazine (stpmag.com)