Local environment “ease of use” as a developer experience metric

How long does it take a developer to make a change on your website?

There’s been a lot of online discussion recently talking about the trade-off between developer experience (DX) and user experience (UX). These are usually based around frameworks which allow developers to be productive, but add weight to the client-side bundles, therefore increasing the time taken loading a web page, and therefore reducing the quality of the user experience.

This discussion has lead me to think about the overall developer experience of working on any web product, and consider a metric I’m calling “ease of use”.

What is “ease of use”?

The concept is simple: given a one-line change which needs to be made on your production website, how long would it take to make that change given you started with a new computer (with a fresh install or an operating system of your choice)?

The time measured should include the amount of time taken to:


Digging in to each of these points can lead to many more questions:

The examples are numerous, but this list should be a starting point for your team or organization to think about what is required for your specific project.

Other environments

Once you have considered your “ease of use” time, it becomes and incredibly useful tool for both onboarding and the creation of other environments. Your ability to quickly build new environments will correlate directly to your local development set up time.

Being able to set up, test, and run your web application locally makes building and destroying environments a much simpler problem to solve. The problem then shifts to become one of build pipelines, and when to create these environments. Jamstack products like Netlify and Vercel attempt to solve this issue with branch deployments, but it becomes a more nuanced issue when databases are involved.


One thing I’ve not discussed in detail here, which is absolutely another part of the problem, is documentation. How are you storing your documentation? Is it with the code in the repo, split amongst the multiple feature repositories, or in a centralized wiki?

How frequently is your documentation updated? Is it a requirement of each pull request that documentation is updated, or is it just updated when an employee leaves the business (and you’re terrified about the loss of knowledge)?

Even if you have an incredibly complex architecture, documentation could be the key to reducing your the amount of time wasted getting a local environment set up.

Side-effects of a poor “ease of use”

This metric is strongly tied to developer morale. If making a change is difficult, if setting up a new machine is difficult, if onboarding new developers is difficult, confidence in the people and the development stack will be reduced.

After every major implementation of a change within the application, this metric should be part of the post-implementation review process.

Whilst the points above are a starting point, you should build a check list tied to your product, and your teams to accurately asses this metric.