The defining characteristic of junkyard coding is the shoehorning of code from an application not designed to be a module into your own code to use some part of it as one. Junkyard coding can also refer to the use of excessive numbers of dependencies, redundant dependencies, and the corrupting of otherwise good software by the inclusion of dependencies not up to the same quality standards. The result is bloated UniformlySlowCode that's difficult to install, troubleshoot, and maintain.

The RubeGoldbergMachine is a very similar anti-pattern / code smell, but the difference is that the RubeGoldbergMachine is too many separate programs working together in a haphazard way while JunkyardCoding is too many (or poorly specced, poorly chosen, bloated, etc.) dependencies/libraries/modules under one hood in the same application.

Junkyard coding often results from an excessive drive (usually by management) to avoid ReinventingTheWheel. It's always a good idea to avoid reinventing wheels if you can, but sometimes you have to.

It can also be caused by the DeathMarch or being forced by management to incorporate a BoatAnchor.

Sometimes this can't be avoided, since sometimes you must shoehorn something into an application to interoperate with a legacy database, protocol, etc. For example, you could use a portion of a Java program like a library if you must use its proprietary protocol but lack the source or a proper module. However, this is bad practice if it can be avoided.

The characteristics of junkyard coding are:

* The shoehorning of applications not intended for use as modules into another application to use a part of their functionality (usually requiring that the entire sub-application be fully or partially instantiated in some really ugly hackish way)

* The use of new dependencies when existing already-present dependencies will do, which often results from a failure to look at the existing dependencies before picking a new one

* The use of big dependencies for minor roles (e.g. including a giant library for one static convenience method)

* The contamination of an otherwise decent project with the CodeSmell of a third party library (see: ExtremeReuse, which can sometimes be a bad thing)

Junkyard coding could also be considered a CodeSmell. Code written in this way will usually have one or more of these characteristics:

* Calling SomeAppsMainClass.main() with contrived parameters inside another application is a sure (and almost "greppable") sign of junkyard code

* An absurdly large memory footprint for what it's doing

* Huge dependency list

* Uninstallable code: requires that files be barfed all over the target machine, requires that special obscure "magic incantations" be performed to get it to work properly, that a totally irrelevant database be installed and configured, etc.

* Poor performance, long start-up time, and high latency

Solution: refactor and sometimes bite the bullet and PleaseReinventTheWheel.
----
CategoryDevelopmentAntiPattern