In addition to writing code, SAS R&D developers are very accustomed to writing poems. I don't mean rhyming poetry like sonnets (though we do hear the occasional randy limerick).

When a developer wants to make a code change in a SAS product, he or she is required to complete a coding impact statement, which summarizes the changes needed, the expected impact, and the amount of testing completed. This statement has the nickname of POEM, which is probably an acronym for something technical but the only thing that comes to mind is Pretty Onerous Explanatory Message. A tester then has to evaluate the POEM and associated tests before approving the change.

Depending on where we are in the development cycle, the POEM requirements can be more or less stringent. For most of the cycle we work with the "short POEM" ("There once was a bug PROC LOAN / that miscalculated how much you can own..."). When we lock things down closer to ship time, we have the more comprehensive "long POEM" (think Hiawatha).

Earlier in the cycle we are permitted to be less formal, so sometimes developers like to run with the POEM metaphor and describe their changes with haiku. Here are a few examples that I found in our bug tracking system.

On the defect where our install check did not report the localized files:

Keith was not yet pleased.
Localized files don’t show.
Now we are global.

On the defect where information map prompts didn't show on first run:

First prompts are silent.
Subsequent prompts loud and clear.
Now all prompts are heard.

On the defect where we didn't report the OLAP Analyzer version in the SAS Enterprise Guide Help->About dialog:

Version of OLAP?
Oops, forgot to even look.
Now we can see it.

A pledge that regression tests have succeeded:

Code changed at Nine Two;
Ran same tests as Nine One Three.
All passed. Can I push?

Sometimes the testers join in on the metered fun:

Testing manager,
Approval via haiku,
Push code on Thursday.