Tech Art Thoughts: Remote Development and "Soft Control" Development Environments

One of the most common considerations I have to take into account in my day job is that of User Environments. Like most technical artists, I do not fully control the machine set-up for most of the people using the tools I help build. 

This is pretty common; as tech artists, we can ask our IT departments to distribute specific software packages, maybe even versions, but beyond that there's little we can do to ensure a given user is set up entirely in line with our wishes, short of us physically walking over to their desktop and checking it for ourselves; an option not always available to us.

Table of Contents

The Three Degrees of Control

There are many ways to describe the degree of control you can exert over a given user's development environment as a software engineer. However, for the sake of simplicity, I like to categorize them using the following three labels: "Overlord", "Squad Chief" and "Distant Observer".

Overlord

In the "Overlord" model, as a developer, you have total control over the user's "Ghost". This means you control the configuration of their machine, which software packages they have installed or are allowed to install, and which version of those packages they must use.

This model is common for IT departments, as it enables the greatest degree of security and stability for the company. However, this level of control is not commonly exercised by Technical Artists. Of course, requests can be issued to the IT department for enforcement of given software packages, and infrastructure can be provided to help distribute new updates.

Squad Chief

As a "Squad Chief", you are in control over a subset of the user's environment. This usually means that as a developer, you enforce a set of packages and their versions, but only for a subset of the user's environment, leaving the user free to install other packages that you don't or can't support "officially".

This is the most common case for internal tools developers, and technical artists. A common example would be that the Technical Art department will ask artists to install a particular version of Substance Painter while using their tools environments to suppress the version update popup, which can be done through environment variables. (I glossed over some of this in my post on DCC environment set-ups)

This type of set-up often spans multiple DCCs; a launcher is provided, and all the necessary variables are set up through its environment. This ensures that when using "officially supported" applications, the user has to launch this application through the launcher, ensuring the tools environment can be properly initialized.

Distant Observer

In the "Distant Observer" model, the developer controls only the environment in the package they're building. This case is the most common for third-party software developers like Adobe, Autodesk, etc... as they cannot (and should not) control the environment their applications are hosted in.

For the user, this allows for a great deal of control; it means the application can be nested in whatever environment it wants to be used in.

For the developer, this means no assumptions can be made, and all dependencies have to be shipped with the package. Resources like images, fonts, language packs, and DLLs are generally provided as part of the package, as we cannot assume the user has them available. This ensures maximum portability, and is great for distribution.

Control vs Portability

You may have noticed a trend in these "Degrees of Control". The less control a developer has over the user's environment, the more portable the package they build tends to be. This is a direct consequence of the inability to make assumptions about prerequisites, dependencies and other infrastructure-level attributes.

How this affects development

In practice, the situation is often not this clear-cut; most developers will find they are somewhere in between. For example, while their tools may be for internal use only, they may not be able to ask their IT departments to enforce a given software package, and therefore find themselves forced to support as many as they can. 

Whatever the case may be, making a note over what you can control in your environment, and what you should be trying to control, can improve your development practices; in my experience, the less control you need, the better. 

Generally speaking, even if you find yourself in total control over your user's environment right now, it is worth considering that this may not remain the case forever, and so it might make sense to go with development practices that assume partial control, or maybe even no control at all. If you then ever need to share your infrastructure with external partners, you might find you have a much easier time doing so.