Spotting smells is valuable, but tough.

Over time, each programmer learns to spot certain kinds of smells. (For example, someone who has had to change a nasty, many-duplicated glob of HTML will be on guard against duplicating globs of HTML again. Instead of copy & pasting, they'll consider adding a method or an object to generate it for them.)

However, each programmer has developed undesirable tolerances.

To sharpen your sense of CodeSmell, try the ChangeBrainstorm:

	1. Assess your current assumptions
	1. Pick one, and imagine changing it
	1. Determine if the code would easily permit this change
		* If not, figure out why not. Is the code OnceAndOnlyOnce'd? Is it clear? Does it have enough tests? Are the tests too tied to the current design? In short: is the code simple enough?
			* Determine if you want to eliminate these obstacles or to say YouArentGonnaNeedIt.
	1. Repeat.

The point is:  Through this exercise, you'll learn to spot more duplication, complexity, and other hindrances to agility.  What you do with smells once you smell them is a more intricate topic.

----

Many of the rules that people have in addition to the XpSimplicityRules are really ChangeBrainstorm's that they carry around with them. Try looking at some code, and asking: "What would happen if I... ?".
	* separated model and view?
	* ''combined'' model and view?
	* decoupled these two classes?
	* coupled those two classes?
	* made it "data-driven"?
	* threw away some part that was data-driven?
	* had to internationalize all of this?
	* split this class by virtue of the OneResponsibilityRule?
	* were to comment this code? (See: CommentBrainstorm)
	* ...

----
CategoryPlanning