Why call it, Refactoring?

At XPDay, two presenters made the point that it helps to explain the practice of Refactoring if you can make code mess more visible. Joshua Kerievsky showed us a movie clip of a listing of a single method laid out page-by-page along the length of a hotel hallway. Kevlin Henney in his talk about Agile Development with C++ presented an silloutte view of a four page method subsequently refactored to a 2 page method. As it happens someone asked me "What is Refactoring?" in the Introduction to XP session. My answer was "Tidying up". It's my opinion that Refactoring is a macho engineers name to hide the true nature of Refactoring so that developers can feel good about doing it. The downside of the cool name is that it is entirely opaque to business people. Here's a simple example of tidying up that parallels the type of thinking developers do when Refactoring. Last weekend, my office was a mess. I had workshop outputs, workshop materials, contacts and papers gathered from the spree of conferences I have been to lately (OOPSLA, Agile Business, XP Days, etc). It was getting hard to find items I needed. Removing the mess was not simple. I had to separate them into different piles and decide where to store them so that they could be easily accessed again - I even went out to purchase new storage boxes and I definitely threw a large pile of clutter away. It's exactly the same with code! If we talked about Code Cleanup rather than Refactoring it might be a little more transparent to management what we are really doing.