Developer experience in Agile application software development

DX in my definition is simply about how the developer feels during the software development process. While DX is usually taken into consideration in making products for the use of other devs such as SDK, editor or libraries, it is also important to take care of this aspect in an application software team so that it can lead to a fine product toward its user and leave the team members much more satisfied with their day job. Within this article’s scope, I will focus on how to enhance the DX for a small-size to mid-size Agile team.

TLDR;

It is to make collaboration effective and automate as much as possible.

1. Set up proper channels for communication and documentation:

• Keep the message groups small and active. Beside the global channel of announcement for everyone, there should be more split groups which focus on a single task and could be ephemeral, or group for separate department (backend, frontend, management) to load balance task and discuss on particular topics.
• Make the documentation regularly updated and easy to look up. The human language does an amazing job when it comes to explanation but make sure that it is mapped correctly to what is happening in the system by updating them from time to time. Also, querying from these sources should be quick and accurate. You know you are doing up this wrong if you have to read through walls of text and get an unexpected result from the given example.
  P/s: My current project is using docz to organize documentation and it is quite pleasing to my opinion.
• Take advantage of the specialized tool. If the team have the budget for tool application, integrate their features into your daily routine and track your productivity to see if it really helps.
  For example, in my current project, we use several tools to keep the work going smooth. Each app covers most of the use case we need on a specific category of work, like:
  - Jira: agile project management tool
  - Zeplin: share, organize and collaborate on designs
  - Telegram & Slack: for group communication
  …

2. Complete guideline of code convention:

For a lot of programming languages and frameworks, there are more than one approach to address a problem and this might create friction while maintaining or continuing to develop other members’ work because of mismatched ways to make things work. Having said that, there are some options to overcome the problem such as using another simplified language like Golang or create constraint on the principle level instead of syntax level among the team. A clear proposal on things such as paradigm, design pattern, repo/ folder structuring, file naming and file’s responsibility should be made at first and then be reviewed by everyone involved in the repo, make sure that they know what / what not and understand why / why not. The whole process should result in debate and then both agreement and compromise in the end until the next review.

For example, in our project frontend’s repo, functions are uniquely contained as the default in verb-named files, and by that it is easy to grasp the overview of functions when browsing the folder’s tree, to see all of them listed out on the surface.

3. Automate fixed procedure:

To avoid human mistakes and save time, effort, enthusiasm of devs. Some procedure can be run automatically, whenever:

- Testing impact after finishing a new feature, upgrading dependency,…
Currently we are using Cypress to running integration test suites to check the stability of our React website. This help increase the confidence of the frontend department on a new deployment or hot fix

- Deploying new version of product onto different environments (dev, stage, production). Applying CICD with tool like Jenkins to test, build and deploy on condition is a good choice.

- Reproduce a production error on local environment. A syncing data across environment to have an exact system state from production will help a lot .

CONCLUSION:

It definitely consumes a substantial amount of resource to create a comfortable virtual workspace for a project but it will prove its value in the long run. And to all the devs out there, please ask yourself if you are traumatizing yourself with a boring and flaky development process, make sure you feel happy in your day job before thinking about delivering a quality software to users. Because as one of my favorite writers once said:

“Một người đau chân có lúc nào quên được cái chân đau của mình để nghĩ đến một cái gì khác đâu? Khi người ta khổ quá thì người ta chẳng còn nghĩ gì đến ai” — Nam Cao