It depends...

You manage the dependencies or the dependencies will manage you.

So I had a recent discussion on what dependency management is. It turns out there are a lot of dependencies, or in other words you are dependent on a lot of different things. First we defined what a dependency is. If you like it to a machine then any moving part big or small is a dependency. From the operating system to the version of a library to version of tools being used. As you see that is quite the number of moving parts.

The goal therefore is to minimize moving parts. Fewer parts is less to manage. Now I am going into software development but I think you can apply the lesson to any discipline.

Start with using kubernetes or Docker. Then have the entire Docker image be ready to run your application. This might entail getting one for cache, one for a database etc. All that is missing is the source code of the application you are developing and maybe some seed data. When that is the case you vastly reduced the moving parts already. Now all developers need is Docker tooling to get it up and running locally. Also when using Docker wherever you will run it you know it will work if it also works locally. *

This is all and well but what if you do not do this? What happens then? Let us make it so you do not use Docker but install everything locally. A certain runtime and some framework. In a few months a new developer joins. He has to install the runtime and framework but runs into a problem. The version the original developer has running is outdated and no longer available. So a new version is installed and everything still runs fine. Mind you we already have a schism. We add a new framework and a couple of libraries and in another few months two new developers start. At this time another runtime is introduced and some libraries and frameworks for this runtime. Now all developers have to install two runtimes and their respective libraries and frameworks. At this moment some developers cannot install the new runtime and the existing runtime has a new version again and that new version does not play well with what has been developed so far. You can quickly see this getting out of hand.

Therefore if you had two Docker images each with one of the runtimes and its respective libraries and frameworks, all developers only need is Docker tooling.

It might also occur that you never update and then you will become more and more insecure. Furthermore the time , effort and infeasibility all grow exponentially towards infinity.

Try to keep up to date once a month. Do audits, upgrades and all of that goodness to not sway too far from the normal line. That way if correction is needed it is never too invasive. **

* Certain mistakes and errors aside that can occur.

** Certain special situations aside

#devops