A system, class, or other software artifact with no ConceptualIntegrity often becomes an Amorphous Blob Of Human Insensitivity. This also happens when an artifact grows rapidly with no refactoring. Some times too much ill-conceived or BadRefactoring can turn a previously decent package or class into an Amorphous Blob. It is sometimes facilitated by Managers that use engineers as little more than interchangeable parts. As a result, the software has no more continuity or definition than the team itself has. This sort of management is usually found at very large companies who reluctantly commit to internal software projects or see software as a ''necessary evil''. In my opinion, this is yet another example of the BorgificationOfEngineering. An example of a class that is an Amorphous Blob is any class that recklessly has everything but the kitchen sink in it. Sometimes even with ConceptualIntegrity you can ended up creating one. You can recognize one by how much you grimace while using it or cringe while reading its documentation. -- RobertDiFalco

''Where do you see this happening?'' - This has always happened and it happens everywhere, see BigBallOfMud. I've used so many classes, languages, and systems that were ''Amorphous Blobs of Human Insensitivity'' that it gives me shivers just to recall them. Early OLE is a good example. Some would even say that the Java Character class is bordering on being an amorphous blob that is insensitive to human beings. When you start thinking of the security model implied by the sum Java 2 Security, JAAS, JSSE, JCE, and JCA, well...let's just say that you can really start seeing some insensitivity there. The primary red-flags are an ''abundance of features'' that literally ''hurt to use'', usually due to the lack of a Common Metaphor. -- RobertDiFalco

I wonder if the authentication and authorization ProblemDomain is particularly susceptible to this.  The Microsoft Authorization Manager libraries seem to be particularly insensitive to any conceivable user; this is exacerbated when trying to use them from .NET.  -- RyanHoegg

I have seen AmorphousBlobOfHumanInsensitivity in the published and (poorly) documented Java interface to the enCommerce getAccess product. As I recall there were a three or four dozen methods on the userAPI class, many of them polymorphic versions of the same function that just took different combinations of the same parameters, or took an array rather than a parameter list. The many-parametered versions were marked as existing only for backward compatibility (though not with the official Java deprecation status) but the array-based versions didn't work. -- StevenNewton
----
See JobSecurity for an Amorphous Blob Of Deliberate Inhumanity.
----
The BigBallOfMud is one place where I was thinking that AutomatedRefactoring would have great benefit.... in our case, staff turnover and aggressive schedules have created a mess, and scripted changes should at least clear up some of the mess....
svend 
----
'''But '''Even the best structured and most meaningful code is insensitive to humans, isn't it? So it's just AmorphousBlob, and even that's redundant.
------
What a coincidence. My wife called me this just the other day.
----
'''See also:''' PlugCompatibleInterchangeableEngineers, BigBallOfMud