Dependency of a piece of technology is another piece of technology that's required for the former to work (typically e.g. a software library that's required by given computer program). Dependencies are bad! Among programmers the term dependency hell refers to a very common situation of having to deal with the headaches of managing dependencies (and recursively dependencies of those dependencies). Unfortunately dependencies are also unavoidable. However we at least try to minimize dependencies as much as possible while keeping our program functioning as intended, and those we can't avoid we try to abstract (see portability) in order to be able to quickly drop-in replace them with alternatives. It turns out with good approach we can minimize dependencies very close to zero.
Having many dependencies is a sign of bloat and bad design. Unfortunately this is the reality of mainstream "modern" programming. For example at the time of writing this Chromium in Debian requires (recursively) 395 packages LMAO xD And these are just runtime dependency packages, we aren't even counting all the hardware features each of this package relies on etc...
Though dependencies are primarily bad because they endanger whole functionality of a program as such, i.e. "it simply won't run without it", they are also bad for another reason: you have no control over how a dependency will behave, if it will be implemented well and if it will behave consistently. OpenGL for example caused a lot of trouble by this because even though the API is the same, different OpenGL implementations performed differently under different situations and made one game run fast with certain combinations of GPUs and drivers and slow with others, which is why Vulkan was created. It is also why some programmers write their own memory allocation functions even though they are available in the standard library etc. -- they know they can write one that's fast and will be fast where they want it to be.
In software development context we usually talk about software dependencies, typically libraries and other software packages such as various frameworks. However, there are many other types of dependencies we need to consider when striving for the best programs. Let us list just some of the possible types:
Good program will take into account ALL kinds of these dependencies and try to minimize them to offer freedom, stability and safety while keeping its functionality or reducing it only very little.
Why are dependencies so bad? Because your program is for example:
Really it can't be stressed enough that ALL dependencies have to be considered, even things such as the standard library of a programming language or built-in features of a language that "should always" come with the language. It is e.g. common to hear C programmers say "I can just use float because it's part of C specification and so it has to be there" -- well technically yes, but in practice many C implementations for some obscure platforms will end up being unfinished, incomplete or even intentionally non-compliant with the standard, no standard can really physically force people to follow it, OR the compiler's floating point implementation may simply suck (or it HAS TO suck because there's no floating point hardware on the platform) so much that it will technically be present but practically unusable. This will mean that your program COULD work on the platform but DOESN'T, even if some piece of paper somewhere says it SHOULD. So REALLY REALLY do not use non-trivial features that you don't really need, it really does help. If you really want to make your program truly dependency light, always ask something like this: "If our civilization and all its computers disappear and only the literal text of my program survives, how hard will it be for future civilizations to make it actually run?".
TODO
Powered by nothing. All content available under CC0 1.0 (public domain). Send comments and corrections to drummyfish at disroot dot org.