Say It Three Times

Pattern or AntiPattern?

Forces:

You are teaching something
You want your audience to remember what you're teaching

Technique:

: SayItThreeTimes. Tell the people what you're going to say in the introduction, say it in the body, and then tell them what you said in the summary.

Expected Result:

Due to repetition, your audience is more likely to remember what you've taught them.

Negative Consequences:

Because of the repetition, your audience becomes bored with the presentation and does not retain the information presented.

Testimonials:

(Please contribute experience-based reports of this pattern succeeding)

Anti-Testimonials:

TomRossen is annoyed by this pattern's usage in RationalUnifiedProcess documents. But does annoyance count as failure? -- JimLittle I'd say that anything that contributes to the discomfort of programmers leads to lower quality and productivity. -- tr
(Please contribute experience-based reports of this pattern failing)

This technique is often recommended, which would normally be enough to make it a pattern. But some people claim it's an anti-pattern... so let's see three testimonials, for or against.

This may or may not be a reasonable pattern for making presentations. But for documentation intended to be written by developers, it just aggravates the annoyance with unnecessary redundancy.

Templates of the RationalUnifiedProcess exemplify this GrayPattern?.

Steps toward refactoring such documentation/templates:

let the TOC be the summary
let the core of the documentation evolve in a Wiki-like manner
keep the doc live with a DocumentMode/ThreadMode dialectic.

See OptimisticProgrammingSkunkworks for an attempt to deal with this problem. -- TomRossen

This exact issue is raised in a Christian context in a book named The Homiletical Plot by Eugene Lowry, in which the author recommends narrative (that is, storytelling) sermons rather than tell-it-to-them-three-times sermons. For an excellent summary, see:

: http://www.kawanabaptist.org.au/Pastor_resources/John_Sweetman/narrative_style.htm

What makes you think this is an AntiPattern? List the expected benefits and the actual (negative) consequences. If you can, describe three unrelated projects that experienced the consequences.

Thanks for prodding me: as you can see from the name change, I've decided it's really a GreyPattern - it may well be useful if you're doing a presentation to bored people who don't want to think too hard. As for concrete examples, almost every document template in RUP (and every other methodology I've seen) has this kind of redundancy. -- tr

Jim - great refactoring! So far it's 2 to zero for AntiPattern (or GreyPattern) - anybody have anything positive to say for it? -- tr

Thanks, Tom. But the score I see is zero to zero: zero primary-source examples of the pattern succeeding, and zero primary-source examples of the pattern failing. Also, to be an anti-pattern, there has to be a negative consequence. What is the negative consequence of SayItThreeTimes? -- JimLittle

Your audience gets bored, and does not retain the information being presented. Good question, though, and thanks for prompting that thought. I've added a "Negative Consequences" section as a result. -- BrentNewhall

Point taken, Jim. I believe another negative consequence is that programmers don't do documentation, do it desultorily, and/or don't keep it in sync with code. But I can't point to specific instances that prove that claim, so I'm not adding it to the Negative Consequences section. -- TomRossen

SayItThreeTimes is effective when you concentrate on providing 3 interdependent messages.

First, you provide a focusing statement telling why you are presenting the information. Second, you provide underlying details to support the initial statement. Without the first statement, the details often appear confused and unrelated to the audience. Third, you provide a request or suggestion on what to do with the information just provided. These 3 things are related, but not redundant.

To use SayItThreeTimes effectively, tell the audience what the issue is, tell them why it is an issue, and tell them how you want them to address the issue.