Hostile incompetence is the phenomenon encountered when somebody completing a task or creating an object- very frequently, an inexperienced computer programmer- discovers that xe does not know how to make the system work, or in general bring the system to a functioning state to meet its goal, and instead of fixing the system to a working state, prefers to take the most expedient route possible to make the system appear to work.
Apparent functionality and actual functionality are often very different things. This node will be focused on the computer programming version of this problem, becaus it is what I have the most experience with. A program that compiles and even runs may be doing very wrong things behind the scenes in ways that hide the real problem of something that does not actually work but was made to pretend it does.
The most common example of this is a popular mechanism for defeating checked exceptions in the Java programming language. A well-written software component in Java will throw an exception when it malfunctions in some way, either from unexpected situations or simple misuse of the functions. Some of these exceptions are checked, meaning the program will not compile until the programmer adds code to deal with these error conditions, because they are actually conditions the program expects to encounter rather than situations that reflect programming errors if they occur. Methods that can throw such exceptions must be wrapped in a try... catch block, and the exception it can throw must be caught and handled, unless the method calling the exception-calling method itself declares that it can throw the exception, in which case the exception is propogated upwards. (This is often the right thing to do when the method doesn't have any effective way to deal with the error condition.)
The Java programming language can check for whether or not an exception is caught, but it has no way to determine if the programmer did something mind-bogglingly stupid in the catch block. The simplest possible perfectly legal catch block has no code at all, and Java allows this with nary a complaint. For that matter, an exception can be caught by catching everything in the Exception class, not just the particular exception that is being thrown.
An incompetent programmer who would rather be incompetent than solve the problem in the way the programming language is telling xir to would therefore squelch the exception by catching all exceptions and giving them a null catch block. This is a classic example of hostile incompetence, when a person being told about xir mistake would rather hide it than fix it.
The serious danger of this particular breed of hostile incompetence is that not only does it squelch the checked exception the programmer was trying to dodge, it squelches every exception to come through that block of the code, including those that by all rights should be fatal errors because they reflect a programming error that needs to be fixed rather than a simple exceptional condition, and leaves no trace of what happened when the error manifests itself much later in the program in the form of bad behavior when the program finds itself in inconsistent state because the exception was not handled appropriately.
An even nastier variant is when a programmer explicitly uses that behavior by deliberately catching an exception that in general has no reason to be caught, such as an IllegalArgumentException or an ArrayIndexOutOfBoundsException, each of which generally reflects an error in the code that needs to be repaired, to make the program run without crashing from the run-time error induced when the exception reaches the top level of the program stack. This was actually encountered by one of my computer science professors, when trying to debug a student's program; it exhibited a malfunction that indicated that her library was getting bad data, but she was confused because this was supposed to cause a fatal exception. She later discovered a catch(Exception e){} hiding this fatal error, in a region where that was the only exception that could be thrown; a few lines before, the function was getting the exact invalid data she had expected, and told her students would not work. Upon asking the student about this genius block of code, she received the reply:
"Well, that's the only way it ran without a run-time error. You should really give us more stable libraries."
The student had not considered that perhaps the exception was there for a reasion and that reason was to prevent abuse of the library.
A library written to be resistant to hostile incompetence must be carefully crafted, and even so, you can make it foolproof, but you can't make it damnfoolproof. A common way of handling this is to set an internal flag that cannot be externally reset just before throwing what should be a fatal exception. The flag is checked in every function call; if it's ever seen to be set, the library knows that a fatal exception was squelched, and it immediately terminates the program with a strongly worded error message.
Hostile incompetence is extremely common among student programmers more interested in making their assignments seem to work than in making their assignments actually work. It has also been seen frequently in commercial software; open-source software is fairly resistant to blatant examples of hostile incompetence as it is usually patched out of the code in short order, but some examples can persist.
Hostile incompetence is not a problem unique to any particular field. Bureaucracy is extremely vulnerable to it, as many of the low-wage receptionists would rather give blatantly and deliberately wrong answers to queries and incorrectly fill out forms than go to the trouble of finding out what the right answer is, or admitting to not knowing the right thing to do. (Hostile incompetence is sufficient to explain the stunningly high failure rate of IRS workers.)
The relatively popular saying of never attribute to malice that which can be adequately explained by stupidity is reasonable, but it is not complete or sufficient. Many things are best described and conceptualized as being the result of particularly persistent and aggressive forms of stupidity that would prefer to propogate themselves than correct themselves, which lies somewhere in that great void between maliciousness and stupidity; this void is filled with the phenomenon of hostile incompetence.