About The Conference

• Date: April 1, 2006
• Location: Niagara Falls, NY
• Register Now
• Interview with Scott Ambler

Keynotes

• Put Testing Where It Belongs--At the End by Brian Marick
• Dead Fish Can't Swim But They Can Float Down a Waterfall by Tim Lister
• Extreme Programming Uninstalled by Ron Jeffries
• Super Model Driven Architecture: An Update From the OMG by Tyra Banks

Contact Information

The Waterfall Alliance
PO Box 1970
Cascade, Illinois

E-mail us

Sponsors

• 
• 
• 

Refuctoring

Jason Gorman

Industry studies show a clear relationship between the maintainability of code and the expendability of developers. In your rush to deliver working software, there's always a danger that you might inadvertently introduce code "smiles". A code "smile" is some aspect of the code that makes other developers smile when they have to maintain it. Common code "smiles" include:

• Common sense naming conventions
• Cohesive and loosely coupled modules
• Elegant abstractions
• Lack of duplication
• A close resemblance to the application domain

Over time code "smiles" build up to create what is sometimes called maintainable code, more specifically, code that can be maintained by somebody other than the person that wrote it, and that means YOU!

Refuctoring is the process of taking a well-designed piece of code and, through a series of small, reversible changes, making it completely unmaintainable by anybody except yourself. Comprehensive regression testing guarantees that nobody will be any the wiser.

Years of experimentation has produced a set of refuctorings that can be applied to the code, to the development process, and to the people on your project. You will learn key refuctorings, including:

• Pig Latin (for naming conventions)
• Stating The Bleeding Obvious--comments that paraphrase the code (e.g., declare an integer called I with an initial value of zero)
• Module Gravity Well - find the biggest module and add all new code to that
• Unique Modeling Language - invent your own visual notations and explain them to nobody
• Treasure Hunt--Code should be made up largely of references to other code. Documents should reference other documents rather than have content of their own.
• Rainy Day Module--you should write spare code just in case somebody needs it later
• Developer Foxhole--if they don't know you're there, they can't ask you to explain your code...

Finally, you will be introduced to the Job Security Index, an industry standard metric for assessing how easily you can be replaced, which you can use to target your refuctoring efforts for maximum career value.

You can download the slides for this presentation.