What do users need from their package dependency management? A lot has already been written on this including the output from a survey of Go developers, a specification for a dependency management tool by those who studied the issue and possible solutions, a series on vgo by Russ Cox, and even follow-up posts by Sam Boyer, one of the dep maintainers. With so many words already written, what more do people need to consider?

When Sam Boyer recently quoted Alistair Cockburn in his write-up on MVS failure modes I realized we aren’t all thinking of people the same way. Dependency management tools are there to aid people. Who are these people and what do they need and want?

The quote from Cockburn read,

We have been designing complex systems whose active components are variable and highly non-linear components called people, without characterizing these components or their effect on the system being designed. Upon reflection, this seems absurd, but remarkably few people in our field have devoted serious energy to understanding how these things called people affect software development.

In one post, that can be quickly read, I can’t go into depth on people. Instead, I want to highlight how people have different opinions on very common problems and that tools need to work for people with these varying opinions.

Package Consumers

Let’s start by looking at those who consume packages. Consider an application developer using libraries. Those dependencies may have their own dependencies, commonly known as transitive dependencies.

When it comes to updating those dependencies how often application developers do it and how many do they update at any one time? The figure below illustrates the variance in responses.

Different organizations and different people are going to have opinions on where they should be on this chart. These differences are going to be based on different philosophies, possibly regulations, views on trust, the difference between a weekend project and production product, and many other things.

If these positions surprise you, yes, there are people who continuously check for dependency updates across all dependencies of an application. They may even do this as part of every CI run. Maybe they pin for releases. There are others who rarely update and when they do they only update one dependency at a time while reviewing all the changed lines of code. In between there are many different levels in use today.

The important element is that a Go dependency manager needs to support people wherever they fall.

Sidebar: Time and Cost

Since dependency managers, especially those that are going to have a monopoly position, need to consider the overall time and cost impact to developers using the tool. For example, if a change can make the workflow faster for thousands of developers there is a collective time savings that can be significant. The opposite is true as well. If a common task increases developer time it can have a negative impact on developer productivity.

With that in mind, let’s consider a common scenario. Many developers want to keep their dependencies up to the latest compatible versions of dependencies. In the Go package management survey, a majority of developers said they wanted this.

To keep up with the latest releases of dependencies is a regular task. The time it takes for someone to perform this task can impact developer productivity.

Note, I’m not suggesting this is the right or wrong way to handle checking for updates. Just that many people do it.

Package Distributors

Package developers are all over the board. Sometimes they are quick to respond to issues, keep up to date on their dependencies, and have their house in order. Other times, they throw something up on GitHub and mostly ignore it after that.

How well something is maintained has little to do with how useful it is. Something fairly simple, such as a random UUID generator, might be pretty simple to replace if there’s a problem with it. Something, such as a YAML parser, is much harder to write and far more difficult to replace.

The figure below illustrates where packages fall in relation to these two ideas.

There are many variables that cause packages to end up at different places on here. For example, there is time, priority, interest, or the difference between being paid to work on it or not. Sometimes the same maintainers will even have different packages at very different spots on this diagram.

Package manager tooling needs to support packages, no matter where they fall on this diagram.

Sidebar: Updates And Unresponsive Maintainers

Let’s take the case of a library package that has a dependency on another package. A security issue is then found in the dependency of the library. For this example, it’s a minor version update to pick up the fix.

The library maintainers are a little slow to update (or maybe very slow) and didn’t even know about the security issue.

Then we bubble up to applications that consume the library. How do they know about and easily get the update to the transitive dependency? How is the experience simple? The focus for many of these application developers is on their applications and not the inner workings of their dependencies.

But, That’s Not How I Would Do It…

Software developers have opinions. They can vary wildly. Foundational tools, such as dependency managers, need to be careful about how much of the workflow they codify into the tools they ship. Especially if the market is cornered.

If you want to go a step further in thinking about people while building tools like this, my suggestion is to start with “Usability 101: Introduction to Usability” by Jakob Nielsen. It talks about how you need usability plus utility to make something useful and goes on to explain, in approachable terms, what usability is.