Optimizing for DX — The Developer Experience
One thing I’m very much obssessed with is something I’m calling the Developer Experience (DX). I’m literally on a global & lifelong mission to optimize DX.
Hint: Once you’re sold on the benefits of a great DX you can skip ahead to the “3 Steps for success” section.
What is DX and why should you care?
If you’re part of a team/organization that does development then you’re likely going to run into one or more of the following:
- Having to keep README’s up to date
- Building & testing your code
- Bringing new people onto the team & showing them how your code works
- Building pipelines & debugging them when they don’t behave
- Fixing your dev environment when it breaks
- Supporting that one person who wants to use <insert whatever OS the rest of the team isn’t using>
- Starting new projects and re-doing the basic building blocks to get started
- Trying to support 10 teams all working on their own software but all needing to be able to work closely together (and not re-invent the wheel)
My perfect world!
In a perfect world the mundane parts of development would be simple:
- Creating a new project should be fast (I shouldn’t worry about any of the ‘boilerplate’ steps that would be the same between projects)
- As a consumer of code: I shouldn’t have to worry about how code is built, tested & deployed
- As a developer of code: I should be able to easily update how my code is built, tested & deployed without affecting other developers or build servers wanting to consume my code
If I have to talk to a developer, install some special software dependencies, read a confluence page or README.md, figure out how to get things working on my OS or spend more than 5 minutes getting your software built or a new project setup then you’ve failed to streamline the DX.
3 Steps for success
The’s a concept called 3 Musketeers which is really just an agreed pattern for standardization when building software. It’s most common form uses Make as a standard interface to Compose & Docker Containers but you can adapt the concept to suit your needs.
3 Musketeers
_Test, build, and deploy your apps from anywhere, the same way. Get Started → Run the same commands no matter where you…_3musketeers.io
The net result is a consistent experience that works the same on Windows, Mac & Linux. It’s portable across development machines, build servers and provides consistency that scales from 1 team to 100 teams.
If you’re already using containers in your build server steps or as part of your development then you’re one step closer to a utopia of standardization!
Containers, and the 3 Musketeers concept can be applied any time you need to simplify a process or some instructions. You can consider it “self-documenting”. A good way to check if you’re giving the best DX is to look at what you need to put in your README to explain your process.
No Musketeers
Just
Install node version 4 but definitely not version 3, and I have no idea about version 5. I’ve you’re on Windows then I can’t help you at all. There are also a few dependencies that you’ll need but I can’t remember what they were. The following 12 page document is incomplete and you’re about to waste half a day that you’ll never get back.
1 Musketeer — Docker
Just run the following docker command:
docker run --rm -v foo:bar -v foo:bar -e FOO=BAR container bash -c ’echo hello world’
2 Musketeers — Docker & Docker Compose
Just run the following compose command:
docker-compose run --rm alpine echo ‘foo’
3 Musketeers — Docker, Docker Compose & Make
Just run the following make command:
make echo
And it’s as simple as that. Developers typically implement steps like “make build test validate deploy” but you can be as creative as you like and write the steps that make sense for you!
Supercharge your development
Using an agreed pattern like 3 Musketeers is a great way to standardize among your teams. As the number of teams you have in your organization grows so too will the benefits. Humans (and those robot automation scripts) will be able to consume your repos more easily and that’s a great thing.
But why stop there?
What if we could template what a good project looks like and deliver that to development teams in a self-documenting and self-updating fashion?
The most basic implementation of this would be writing a “hello world” application and asking your development copy/paste the code when starting new projects.
But there’s a tool called https://yeoman.io/ and it provides scaffolding for modern web apps. It’s another simple yet impressive concept executed well. What it provides is a templating mechanism with a really slick user-input feature and enough glue in-between to great that amazing DX we’re all chasing.
With yeoman development teams can setup and maintain examples of good software delivery with teams benefiting from the learnings of others. You can create a generator for just about anything, so the only thing left is your imagination!
Yeoman has it’s own generator to help you create your first generator (how meta, right?). The only thing missing for me was a reliable docker container to do some development in. I created a repo with a yeoman development container to make life easier. Hopefully you find it useful and make some steps to improve your own DX!
drewkhoury/devyo
_yeoman container - for local development of yeoman generators - drewkhoury/devyo_github.com
Want more?
Presentation (PDF): Optimizing for DX in a Cloud Native world
Presentation (Video): https://www.youtube.com/watch?v=ZYlbNnaoseI
Also posted on medium as Optimizing for DX — The Developer Experience.