Definition

dependency hell

This definition is part of our Essential Guide: ALM best practices for advanced DevOps organizations
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.

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

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

2 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

When was the last time you were in dependency hell and how did you get out?
Cancel
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.

Cancel

-ADS BY GOOGLE

File Extensions and File Formats

Powered by:

SearchDataCenter

SearchAWS

SearchServerVirtualization

SearchCloudApplications

SearchCloudComputing

DevOpsAgenda

Close