'''AntiPattern Name''':  StandingOnTheShouldersOfMidgets

'''Type''': Design | Organizational 

'''Problem''': You're working in an organization that dictates that you reuse code in libraryX to solve the problem you're working on.  Looking at this API, you find a jumbled mess of cluttered concepts and weird hacks, or it doesn't do half of what you want it to do.

'''Context''': This pattern can show up not just with code libraries, but also with general architectures and databases.  For example, the organization might be using a hand rolled messaging system with various limitations, or a hand rolled database with peculiar semantics, or a complicated/convoluted/contorted project management methodology.

'''Forces''':  
* Hubris: The developer/manager/owner of libraryX wants everyone to use it, regardless of how bad it is.  They wrote the library, and you better use it!
* Laziness: Its too much work to change libraryX, and besides, everyone who uses it would have to change as well, so just go through the gynmastics and stop complaining!
* Fear: We don't know what could happen if you change libraryX, and we're afraid of what might happen if you do.

'''Supposed Solution''':  Go through the code gymnastics to set up arguments to libraryX as it wants them

'''Resulting Context''':  

*You end up feeling dirty about the code you wrote to interface with libraryX.

* Seductive forces:  Code reuse is a good thing, right?  Re-inventing the wheel is a bad thing, yes? 

* Why, despite the seductiveness, this is actually a BadThing: 
** Your code ends up being difficult to understand and maintain
** Strong coupling between your code and the libraryX code 
** Further entrenchment of libraryX as an essential library for everyone to use

* Replacement positive patterns:

** RefactorMercilessly: Refactor out the ugliness from the public API to libraryX
** AdapterPattern: Write an adaptor around the public API to libraryX that hides the ugliness.  Possibly introduce this adaptor into the library so other people can easily reuse it.

'''Design Rationale''': Midget libraries can evolve in all sorts of ways. 
* The public API was poorly thought out
* When the code started to smell, no refactoring was done
* ...others?

'''Related AntiPattern''''''s''': BigBallOfMud, GoldenHammer, IfItIsWorkingDontChange

'''Applicable Positive Patterns''': AdapterPattern

'''AntiPatternCategory''': DevelopmentAntiPattern, ArchitectureAntiPattern, ManagementAntiPattern 

'''Also Known As''': 

----
'''Examples in the Literature''': 
----
'''Examples in Practice''':
----

--LyleHayhurst

----
CategoryAntiPattern CategoryArchitectureAntiPattern CategoryManagementAntiPattern