Holy cow, I wrote a book!
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.
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
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?