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

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:

• Download all required programming languages and tools
• Clone all required repositories
• Run a local development version of your whole stack
• Make a simple change - this could be front-end, back-end or even a config change
• Test that change locally
• Push to version control
• Check on any staging or UAT environment
• Run all the required unit, integration and end-to-end tests
• Push to production
• View the change on the production website

Considerations

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

• Can your developers run a full-copy of your website locally? Or is this a problem you simply haven’t solved yet?
• Are you reliant on cloud-only SaaS tools which cannot be used locally? Have you tested your local developer experience offline?
• How many programming languages and tool-chains are required for your core web application?
  • And are your developers fluent in all of these languages, or only some of them?
• Are you using a tool like Docker, to reduce the set up friction and allow easier cross-platform development?
• How many repositories does a developer need to download to have a copy of the full environment?
• Do you have an empty shell repository which downloads other repositories, therefore allowing users to only request a single repo? Or are you using a monorepo, with all the required code checked in?
• How can a developer find the location in the codebase where they need to make a change?
• How clear are your errors messages when developing? If something goes wrong, is a single developer able to debug by themselves?
• Is the process fully automated or just a hastily cobbled together set of poorly maintained bash scripts, which everyone is afraid to modify?
• Is it clear within your organization who can help developers set up their local environment?
• Who is responsible for developer environment support and maintenance?
• Who is responsible and who makes the final decision on any changes to local development?
• Is there a single location (be that Slack, Teams, or a forum) in which a developer can ask for help?
• Can a developer download a copy of production data (with personally identifiable information removed) and use it locally? Or do you only use fixtures and fake data?

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.

Documentation

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.