Most often associated with server attacks (e.g. DoS) brute force simply uses all available resources to achieve a given end, without prioritization.
This is often what people try when they don't know what the problem is, but in an even less efficient way than they could. Brute force is blunt but thorough as it should cover all possibilities.
If you're short of ideas and losing your sanity, brute forcing the problem can help because it confirms that you really know what's going on. Start by listing all the tests that have to be run and go through them, one after the other.
Relates to trial and error. Be aware of which you're following because they have very different running times. Brute force takes the time to go through all possibilities. Trial and error cuts through many of them. The reason that people fall into brute force from trial and error is that information and evidence is ignored. One of the trails will throw up an expected result, or an inexplicable result and the debugger (the person) will ignore it, moving on to the next possible cause. This isn't bad, but is a very different process from trial and error.
Brute force is good when you know all the possible things to test. If you don't, you have no way of knowing whether you've completed or not. If you fall into brute force, for goodness sake make sure you have a finite list of everything you can think of, even if it isn't truly exhaustive you can use this to know whether your understanding of the system is hiding some possible causes from you.
How long does brute force take? In algorithm terms brute force is a bit crap. If there are 100 possible ideas it'll take up to 100 iterations to find out if any of your ideas are right, which is good if you can afford time for the 100 tests for each idea. If you haven't already thought of the cause, the time to fix is going to include running the 100 test plus the time to come up with the new idea and run tests for that, so the 100 tests might just be time wasted.
So how do you know if you're about to waste a load of time? Brute force is excellent when you have no idea what the cause could be but you need more information. Running through our hypothetical 100 tests may take some time but if it does one of the two possible things - shows what the problem is or shows that we haven't thought of the problem - we're screwed.
Be warned though as there are two types of brute force: brute force testing of ideas and brute for fixes. Brute force fixes are the work of idiots. Brute force fixing is this: you think it's something and fix it as you think of it, in the worst case this gets straight into production with even the most technically aware believing that the fix will help. Brute force fixing is only for desperate times.
Brute force testing is good, because it ensures you have complete coverage of all possible causes. It also benefits from being a known time for testing.
Brute force is not good at taking account of new information, because by definition it sees you walk through every possible cause.
