In its most general sense, the term bug farm refers to something that is a rich source of bugs.

It is typically applied to code which is nearly unmaintainable. Code can arrive in this state through a variety of means.

  • Poor initial design.
  • An initial design that has been pushed far beyond its original specification (resulting in features built on top of other features in weird ways).
  • Overwhelming compatibility constraints such that the tiniest perturbation is highly likely to cause some application somewhere to stop working.
  • Responsibility for the code residing in people whom we shall euphemistically describe as "failing to meet your personal standards of code quality."

The term is most often used as a cautionary term, calling attention to areas where there is high risk that code you're about to write is going to result in a bug farm.

Aren't we setting ourselves up for a bug farm?
This could easily lead to a bug farm from different lifetimes for this various state objects.

The term is quite popular at Microsoft (pre-emptive snarky comment: because Microsoft software is all one giant bug farm). Here are some citations just from blogs.msdn.com:

Layout runs under disable processing. The reason we did that is because, well, reentrant layout is a bug farm.
A lot of testers suddenly realized that case sensitivity is a veritable bug farm on a project that thinks it is ready to go, but has not yet tried it.
That type of implicit vs. explicit inference also turned out to be a bug farm.
Did you forget to handle an entire set of test cases? Is the features implementation overly complex and going to be a bug farm?