Minimize the number of runtime dependencies


Hello, you must be a programmer, and you probably like coffee (there’s a reason some programming tools have coffee-related names). Well, then you have a coffee machine, correct? Let’s make some nice hot coffee for us to enjoy while reading this blog. Put some beans in there (it’s a luxurious machine, alright?), pour some water in the reservoir, and put an empty cup under there. Push the button to bring the machine to life, and after some whirring should you see the black gold oozing out of it. Nice…

While we’re at it, let’s take a closer look at the coffee machine and the process of making coffee. It’s actually quite a hassle to setup your coffee machine, as it depends on water and beans and such. In contrast, the coffee machine here at work is connected to the water mains, and a lovely coffee person tops the beans up every week. All I have to do is put my cup under there and push the button. Instant coffee!

The work coffee machine is easier to use than my home coffee machine, since it has less runtime dependencies. Yes, those things the user has to supply for a tool or device to work are not limited to the applications you write. Everything that can be used has runtime dependencies. The tool you wrote last week needs a remote Apache server with a MySQL database, and the vacuum cleaner you bought needs bags and power. These are things a user will have to supply before the product can do its job.

More runtime dependencies take more time to setup, are more complex to understand, and give more possibilities of failure or user error. Maybe this feels trivial, but it’s something most designers don’t consciously think about. While many products have at least one runtime dependency, the best products are those that have no runtime dependencies at all. A great example is the disposable camera: if you have it, you can take pictures with it. It just doesn’t need anything, it has no runtime dependencies.

Alternatively, if you can’t remove a runtime dependency, try to hide it instead. In physical products, runtime dependencies are often combined. Your color inkjet printer needs only two cartridges, even though it uses four colors. In an application, you may hide the runtime dependencies in the installer: the user doesn’t have to deal with most of them, the installer takes care of it.

So, to improve the adoption and accessibility of your product, try to minimize the number of runtime dependencies. But if that’s not possible, try to hide them as much as possible.