Desire paths and shadow IT

Any substantial use of a system or solution will usually result in some sort of workarounds where users will try to get what they want if it’s not officially or adequately supported. Chris Siebenmann documented an example of users running heavy jobs on the university’s login server, something it’s not designed to do. This undesired usage was described by him as a desire path:

In a university, what you get in practice is more like a field with a certain amount of desire paths in it. You can build paths and exhort people to not step on the grass, but they’re going to do it anyway. And obviously, the more pathways you don’t build, the more people are going to make their own paths.

I quite liked this description, in a corporate environment this type of user behaviour would be labelled as shadow IT. It has a sort of menacing ring to it. If the user does something that works around a limitation to accomplish a task, it’s likely they lack the tools or guidance on doing that thing in the first place. Calling it a desire path frames it in a much more accepting way that pushes IT to improve support for or accept this sort of behaviour in some cases.

The UK’s National Cyber Security Centre’s (NCSC) article on shadow IT also makes this point:

If employees are having to resort to insecure workarounds in order to ‘get the job done’, then this suggests that existing policies need refining so that staff aren’t compelled to make use shadow IT solutions.

The article then goes into options where shadow IT should not be tolerated especially if it poses a security risk or risk of data theft, which is definitely understandable.

In the few years I’ve helped businesses build tools and systems I’ve never heard user workarounds be described as desire paths, but that’s exactly how I’ll be referring to it from now on.

In a somewhat related vein is the reliance of an undocumented behaviour of a system, described through Hyrum’s Law:

With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.

This at times might be unintended, for example, many years I ago I built a script that helped keep track of new posts on various subreddits. I unintentionally added a second / in the URL path. This went unchecked for years before it was fixed by Reddit and I got an error. It took some time for me to figure out that I was dependant on this undefined behaviour without my knowledge! It’s a simple case, but this gets much more difficult when maintaining larger systems.

In other instances, a dependency on an undocumented behaviour might be intentional. If for example, the solution doesn’t make adequate access available to certain features it’s common to see technical users work through internal APIs that don’t normally carry the same grantees a public facing interface might.

I’d like to classify the latter as a desire path as well.