Developer eXperience (DX) matters

Our organizations are made up of people. 

Just as we want to provide the best experience for our customers, we should also want to take care of the experience of our development teams. After all, behind every enterprise software, there’s a group of developers who have to make it work.

Being a Developer 

Being a developer is more than ... 

• a career
• just a job
• just working alone at your computer
• just writing code
• problem-solving
• patterns, practices and new frameworks
• knowing every language or syntax
• knowing the hottest tools

As Zeno Rocha points out, "Enterprises often underestimate the importance of developer experience".

On a scale of 1-10, how happy are your developers?

Developer eXperience

Developer eXperience (DX) encompasses all aspects of the developer’s interaction with the organization: It is not just tools and systems, it is s also about documentation, automation, processes, metrics and using them all effectively

You should consider (if you haven't yet done so) working (and improving) on Developer eXperience (DX), to increase your team’s morale, productivity, speed, engagement and so enable them to reach their full potential.

Instead of having your development teams fighting against tools or processes to get their job done ... How can you make a workday better for them?

Making life easier for developers can improve the bottom line and speed up innovation while keeping them happy.

Going beyond the “Gut Feel”

When it comes to software development, anything that is worth doing is also worth measuring and, so one of the key steps to improving DX would be to measure it.

These metrics should be defined and used as tools to allow developers to measure progress and improve themselves, but not as a way to evaluate their performance.

"Being a developer is not only about writing code. And improving as a developer is not only about improving in writing code" - Sebastien Castiel

Measuring Developer Experience

While not everyone define the same metrics, I would suggest to start with some basic ones:

Deployment Frequency: Number of releases per day.

• If it’s low, you may not be delivering enough value.
• If it’s high, a risk is not QA'ing the code properly, which could lead to low quality (lots of bugs).

Time to merge: The amount of time from first Commit to PR Merged.

• If it's high it could be an indication that you’re lacking automation

Time to release: The amount of time from Pull Request Merged to Production Release.

• If it's high, it could mean you need to invest more in continuous deployment (CD)

Code churn: Amount of code that a team had to change, remove or add during a work period.

• If it's lower, you look efficient and productive.

Mean time to recover/repair (MTTR): Time between discovery of a bug or security breach and a deployed, working remedy. 

• If it grows smaller over time, you’re becoming more effective in understanding and fixing bugs and security issues.

Toil cost: Time and effort spent on doing manual, repetitive and reactive tasks.

• If it's high it could be an indication that you’re lacking automation

Flaw escape rate: Number and severity of defects that get discovered by users.

• If it's high may mean that you are under-engaged or that you received a very opaque set of requirements.

There are many more metrics that could be considered: WIP, Cycle Time, Leadtime, Review request waiting time, Unreviewed Pull Request Ratio, Application Crash Rate, Code smells count, Latency of subsequent deployments, Buffer time for refactoring, Local development environment satisfaction, etc. 

Yes, Development eXperience needs investment, but it pays off, and beyond that, IMHO, it’s one of the next major competitive fronts in enterprise tech.

“In the software world, the company's most important assets go home every night. If they are not treated well, they may not come back the next day”