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?

Comments (9)
  1. Dan Bugglin says:

    Sadly I can apply all four of these bullet points to our current project… I'm already making notes about how to blow away various poorly designed subsystems after this delivery and replace them with something better designed.

  2. Anonymous says:

    Responsibility for the code residing in people whom we shall euphemistically describe as "failing to meet your personal standards of code quality."

    I call them colleagues.


  3. Anonymous says:

    I'm sure it's just coincidence, but this post looked extremely familiar to me… blog.brandonbloom.name/…/bug-farms.html :-)

  4. Anonymous says:

    Cause 3 (and perhaps also 2) leads to Arthur C Clarke's third law of software engineering: Any sufficiently successful piece of software is indistinguishable from a coding disaster area.

    My ambition, as a programmer, is to be responsible for a really major disaster area. (In a similar vein, I hope one day to pay a truly enormous amount of tax.)

  5. Anonymous says:

    Heh. When I saw the title of the article, I thought maybe it would have some connection to this:


    But I guess I was wrong. At least, I hope so. :)  While I always cynically suspected some of my coworkers at Microsoft were taking advantage of the screwed up "highest bug-fix count wins" approach to employee performance measurements by intentionally writing such buggy code as they did, surely that was not really a significant source of bugs.

  6. Anonymous says:

    Halfway through the article, I was beginning to formulate a list of MS products for each of the four bullet points, but then I got to the "pre-emptive snarky" bit and decided to keep my trap shut :-)

  7. Anonymous says:

    At my place of work we tend to see a lot of point 2, luckily not so much of 3 and 4, and sometimes point 1 (but not too much of that either, point 2 definitely takes a big lead).

  8. Anonymous says:

    Most internal I/T departments (both in-house and outsourced) don't throw enough time/resources at projects to expect outcomes different from the bullet points above.  Tech companies should be mostly exempt, but we all know Microsoft has taught us there are dramatic exceptions.

  9. Anonymous says:

    That still leaves us with the "by-design" bugs that microsoft software have.

    Does "by-design" mean: Milk the suckers of support money while not having to do anything ?

Comments are closed.