StandingOnTheShouldersOfMidgets

Last edit August 14, 2010
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 AntiPatterns: 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