Dependencies – one more variable adding to the “cost of the code”
One thing I have to explain a lot is what are the costs of software development. Why are things taking so long? Why is there any needed for maintenance and support? Why are developers spending significant amount of their time looking over the existing code base and why we can not just add the next and the next feature?
Today I have an example of this – and these are “dependencies”.
The goal of this article is to give people more understanding on how the “tech works.”. I’ve seen that every line of code and every dependency that we add to a project will inevitably result in further costs down the road so we should really keep free of unnecessary dependencies and features.
Daily builds
Many contemporary professional software projects have a daily build. This means that every day at least once the project is “built” from zero, all the tests are run and we automatically validate that the customers could use it.
Weekly dependencies updates
Every software project depends on libraries that implement common functionality and features. Having few dependencies is healthy for the project, but having no dependencies and implementing everything on your own is just not viable in today’s world.
These libraries and frameworks that we depend on also regularly release new versions.
My general rule that I follow in every project is that we check for new versions of the dependencies every Wednesday at around 08:00 in the morning. We check for new dependencies, we download them, we build the project and we run the specs/tests. If the tests fail this means that the new dependencies that we’ve downloaded have somehow changed the behavior of the project.
Dependencies change
Most of the time dependencies are changed in a way that does not break any of the functionality of your project. This week was not such a week. A new dependency came along and it broke a few of the projects.
The problem came from a change in two dependencies:
Fetching websocket-driver 0.7.5 (was 0.7.4)
Fetching mustache-js-rails 4.2.0.1 (was 4.1.0)
Installing mustache-js-rails 4.2.0.1 (was 4.1.0)
Installing websocket-driver 0.7.5 (was 0.7.4) with native extensions
We have installed new versions of two of the dependencies “websocket-driver” and “mustache-js-rails’
These two dependencies broke the builds.
Why should we keep up to date
Now out of the blue we should resolve this problem. This takes time. Sometimes it is 5 minutes. Sometimes it could be an hour or two. If we don’t do it, it will probably result in more time at a later stage. As the change is new in ‘mustache-js-rails’ we have the chance to get in touch with the developers of the library and resolve the issue while it is fresh for them and they are still “in the context” of what they were doing.
Given the large number of dependencies that each software project has there is a constant need to keep up to date with new recent versions of your dependencies.
What if we don’t keep up to date?
I have one such platform. We decided 6-7 years ago not to invest any further in it. It is still working but it is completely out of date. Any new development will cost the same as basically developing the platform as brand new. That’s the drawback of not keeping up to date. And it happens even with larger systems on a state level with the famous search for COBOL developers because a state did not invest in keeping their platform up to date for some 30+ years.
Reply
You must be logged in to post a comment.