Change Brainstorm

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
2. Pick one, and imagine changing it
3. 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.
4. 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