dependency hell

Contributor(s): Austin Allen

Dependency hell is a negative situation that occurs when a software application is not able to access the additional programming it requires in order to work. In sofware development, additional programs that software requires are called dependencies. Sometimes known as JAR hell or classpath hell, dependency hell's common outcomes include software performing abnormally, bugs, errors messages when trying to run or install software, or the software ceasing to function. Many times, these software dependencies are developed by third parties.

The cause of dependency hell is varied, but it usually happens for one of four reasons:

  1. The main software relies on a multitude of large software libraries, causing lengthy downloads and decreasing the portability of the software. Even if an application requires only a small portion of a large library, the whole library must be downloaded.
  2. The main software creates a chain of dependencies, where the software relies on product A, but A relies on product B to function, and B needs product C to work properly.
  3. Conflicting programs that require different versions of software or libraries to work. Application X requires software FF version 2.0 to work, while application Y requires software FF version 2.5 to work, and both versions of FF cannot be installed at the same time.
  4. The software's requirements create circular dependencies. Application Y version 3.1 requires software EE. Software EE requires application W to work. Application W depends on software HH. And software HH relies on Application Y version 2.6.

These dependencies can be a major headache for users and software creators alike, hence the hell designation. However, package managers and automated testing have incorporated dependency checking tools to alleviate some of these dependency hells.

Content Continues Below

Advanced application development and deployment environments such immutable infrastructures are a great means of avoiding these kinds of dependency problems and uncontrolled change. The IT team can package and deploy an app in a self-contained manner. When a change is made, the entire image is recreated and redeployed, not patched in-place.

This was last updated in August 2016

Continue Reading About dependency hell

Dig Deeper on Application Rollout Planning and Problems

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

When was the last time you were in dependency hell and how did you get out?
Testing tool vendors sometimes struggle to keep up support for new and old versions a like.
In one situation, the legacy app we tested used a technology no longer supported by the testing tool. There was no way around.
In another case, updating to a newer version of Silverlight broke the entire automation suite - until we were able to get an update for the automation tool.


File Extensions and File Formats

Powered by: