This article explains what Dependencies in Programming mean.
This article is going to be a very informative read no matter what kind of programmer you are. In fact, even if you aren’t a programmer you will find this article useful. After all, dependencies is not just a programming concept. It’s a general term that has meaning even outside of Computer Science.
Table of Contents:
- What are Dependencies
- The Dangers of using Dependencies
- Why we use Dependencies
- Picking the right Dependency
- Further Reading
What are Dependencies
Dependency is a broad software engineering term used to refer when a piece of software relies on another one. Simply put, if Program A requires Program B to be able to run, Program A is dependent on Program B. This makes Program B a dependency of Program A.
You may ask, why would Program A even need Program B, or any other program for that matter? This will be further elaborated in the “Why we use dependencies” section in this article, but a short version is that Program A requires a special service or feature which Program B has.
It doesn’t really matter what it is, if your program needs to run correctly, it’s a dependency. Common examples of dependencies are programming libraries, Online services, programming scripts etc.
If you’re a Python programmer reading this, I recommend you check this article on Pyinstaller as well. It also has alot to do with Dependencies, converting python files to exe’s and distributing software, a very informative article overall.
The Dangers of using Dependencies
Having dependencies for your code is generally frowned upon. As we explained earlier, it reduces the flexibility of your code and worse case scenario, it can completely ruin your program. Before we get into this though, we’re going to categorize dependencies into the two follow categories.
- Dependencies that we control
- Dependencies that we do not control
Uptil now we’ve mostly been talking about the first category, dependencies which we have direct control over, such as a custom library that you may have wrote. Now we’ll briefly discuss the second category, dependencies that we do not control.
Unlike dependencies that you have direct control over, (like a custom library) dependencies that you do not control have a much higher risk factor involved. What happens if one of the dependencies suddenly shuts down or goes through some kind of drastic change (breaking your program in the process), what will you do?
There have been cases where a company completely based their application around a dependency or external service and it was shut down suddenly, causing them major losses.
Of course, this doesn’t mean you shouldn’t be using dependencies. Most of the time you won’t have a choice anyway. What you can do however is minimize the risk involved by choosing your dependencies smartly.
Why we use Dependencies
At this point you may be wondering, “why do we even use dependencies if there is so much risk?”. That’s a good question, and the answer is pretty simple and straightforward.
Applications are becoming more and more complex day by day. The average amount of code behind an application is also increasing day by day. If each one of us started from scratch each time, we would barely make any progress.
What we do is to carry forward what has already been tried and tested and then further build upon that. Basically, we save time by using pre-written and tested code, and then use the time we saved to create new and better things.
This is actually one of the major reason Python is so popular. There are so many Python libraries with pre-written code for various scenarios, that a new programmer can build complex and advanced applications within a few weeks using these libraries.
Reinventing the wheel
You may have heard of this expression, “reinventing the wheel”. It refers to the act of creating your own version of something that has already been created. Trying to reinvent the wheel is generally a highly discouraged practice in programming (with few exceptions).
The reason for this is quite simple. If a widely tested and adopted service/library already exists, why waste the time and effort making your own version which is probably going to be subpar to the one that already exists.
To sum up, we use dependencies to avoid having to reinvent the wheel, to speed up our coding process, save time and increase efficiency. Let’s say you have a software that requires location data for a certain part, are you going to create an entire service that provides location data? Of course not, you’re going to use a pre-existing location service to provide you that data. It could be the difference between writing 10 and 10,000 lines of code.
Things to look for in a Dependency
A couple of important things to keep in mind while selecting a dependency.
- Portability: The last thing you want is a dependency that only works on certain systems and platforms. Unless you only plan to release your application on a certain platform, you should definitely research your dependency carefully and even pre-test it on the platforms you’re aiming for.
- Version control: Be mindful of the version you pick for your dependency. You should already know this, but each new version brings in new features. If you’re using the latest version of that dependency and your customers/clients have a slighter older version there might be issues. You also have to consider how you will be managing your update schedule.
- Regular Updates: This is both a security issue, and also an indication that this dependency could abandoned entirely in the future. If the dependency you’re looking to use hasn’t been updated in a year, it’s best to avoid it.
- Adoption rate and usage: You’ll usually find several different possible dependencies you can use for your program. You should aim for the one has been widely adopted in it’s respective field and is actively being used. Not only does this show the dependency is reliable and trustworthy, it also indicates that the community for this Dependency will be large. Popular dependencies are thoroughly documented and discussed across the internet, making troubleshooting or asking for help easier.
- Compatibility: The last thing you want is to pick a dependency without properly researching it and later finding out that it wasn’t compatible on all the platforms you were aiming for. This problem is more common than you may think. There are all kinds of issue that may be involved so be sure to do your research before hand. As another suggestion, while coding keep testing your code on different platforms and settings. You don’t have to leave all the testing for once you’re done.
An example of a good third party dependency would be Google Maps. If you build an application that requires locations services, you could use the Google Maps API to retrieve location data. I say this is a good dependency because:
- Google Maps is managed by Google, a large company.
- Google Maps as a service is used globally, hence you can expect it to be reliable and consistent. You don’t have worry about this service vanishing over night or something.
- The Google Maps API is simple and easy to use. It has a free version with a limited number of requests and a premium (paid) version as well. For most cases the free version is perfectly fine.
If you’ve been coding for a while, you’ll also have undoubtedly used many libraries too. About 95% of the time using these programming libraries as your dependencies is perfectly fine due to how widespread their use is. As a bonus, it’s not too hard to bundle up these libraries into a compiled program either using something a file to exe converter like pyinstaller (for python programs).
You should however avoid libraries which are outdated and have very little support. Basically just keep an eye out for everything we mentioned in the previous section.
Be smart and pick wisely!
Dependencies in programming is a topic over which an entire book can be written. There’s alot more to them than what was covered in this article, so if you’re interested we’ve included some resources here for further reading.
If you interested in hearing more about dependencies and their dangers in programming, I suggest you read this article.
This marks the end of the “What are Dependencies in Programming” article. Any suggestions or contributions for CodersLegacy are more than welcome. Questions regarding the article content can be asked in the comments section below.