Microspeak: The bug farm

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?