Code craft: February 2008 Archives

How not to do a Changes file

| | Comments (5)

Here's how to not do a Changes file:

http://search.cpan.org/src/FELICITY/Mail-SpamAssassin-3.1.5/Changes

That tells me nothing about whether I want to upgrade my SpamAssassin install. :-(

Oh, look, I wrote about this before, and how great Tim Bunce's Changes files are.

From David Fetter's page at http://fetter.org/optimization.html:

  1. The first rule of Optimization Club is, you do not Optimize.
  2. The second rule of Optimization Club is, you do not Optimize without measuring.
  3. If your app is running faster than the underlying transport protocol, the optimization is over.
  4. One factor at a time.
  5. No marketroids, no marketroid schedules.
  6. Testing will go on as long as it has to.
  7. If this is your first night at Optimization Club, you have to write a test case.

Of course it's company policy never to imply ownership of a performance problem. Always use the indefinite article: "a performance problem", never "your performance problem."

About this Archive

This page is a archive of entries in the Code craft category from February 2008.

Code craft: January 2008 is the previous archive.

Code craft: March 2008 is the next archive.

Find recent content on the main index or look in the archives to find all content.

Other Perl Sites

Other Swell Blogs

  • geek2geek: An ongoing analysis of how geeks communicate, how we fail and how to fix it.

Code craft: February 2008: Monthly Archives