dependency hell
What is dependency hell?
Dependency hell is a negative situation that occurs when a software application is not able to access the additional programming it requires to work.
In software 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.
What causes dependency hell?
The cause of dependency hell is varied, but it usually happens for one of four reasons:
- 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.
- 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.
- 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.
- 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 as 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.
