Developers balance speed and quality to satisfy customers and keep up with market demand. But burnout can set in as developers must work faster with perfect accuracy.
Most software development organizations today embrace the DevOps philosophy, leaving on standard practices and tools to make developers' lives easier. But, moving beyond the traditional methods of DevOps today, how can we improve developer experience?
One of the best places to begin improving developer experience is with the deletion of the slow. Say goodbye to tests, tools, and practices that bog down developers and slow execution times.
One of the best places to start deleting the slow is legacy tests. These are tests inherited (perhaps from previous employees) or have run for so long that they are universally accepted as a part of the workflow, without question.
However, it may be unclear exactly what the test is for when you genuinely look at legacy test code. Or, if the legacy test is old enough, the commit history might reveal a multitude of patches, each patch the bare minimum to keep the test wheezing along.
If the legacy test value is questionable, or they slow down execution, it’s time to delete the slow and remove them.
However, removing a test can be scary and requires team buy-in. That buy-in isn’t without warrant. Most team members likely don’t know which of the tests run the longest or exactly how long that run time is.
Removing roadblocks like legacy tests is a great way to start if you want to improve developer happiness. Start small and remove a single legacy test to pave the way to more effective processes and ultimately speedier, more effective development.
Another great way to improve developer experience is to drive awareness of flaky tests. Create a culture of communication and reporting around flakes to ensure flaky tests are not rerun. This attitude towards flakes sets the bar high and ensures faulty tests are not tolerated in the environment.
Note we didn’t say remove all flaky tests. That’s almost a near impossibility and not necessarily even a good idea. Flaky tests happen. There’s always some chaos in the SDLC. The goal is to contain the chaos, not burn valuable time and energy on driving the chaos down to zero. Why not? The returns start to diminish. It’s like email. You might get to “inbox zero” on Monday (and take hours to do so), but you’ll wake up on Tuesday morning with a brand new batch of new emails to tackle.
It’s the same with flaky tests. The critical mindset to take with flaky tests is to figure out the right level of chaos or flakiness that can be tolerated and handled without significant disruptions to workflow.
Another significant way to improve developer experience is to practice better test selection and embrace only testing what’s needed.
Let’s explore this principle with an example. A developer needs to change the front end of a project. Previously, any change to the central repository would result in running the entire test suite. This creates a lot of computation cycles for the overall cost of the program, as well as the Donor feedback cycle. Improve developer experience and only test what matters. In this example, the change could be made solely to the frontend so that backend testing could be skipped.
By reducing the number of tests run and skipping unnecessary tests, developers can speed up their entire test suite. And that leads to working faster, speedier execution times, and a better developer experience.
Reducing test execution time is the equivalent of paradise on Earth for developers. That’s why the fourth action to improve developer experience is to slash testing run time.
Choosing only the most important tests to run is critical if you want to slash test execution time. Additionally, it’s also vital to lessen the total run time of each selected test.
A great way to do this is through unit testing, done in order of prioritization of test importance. Two ways to accomplish this is to include eliminating redundant tests and combining tests to achieve similar results in a faster time. For example, if a single file contains a hundred test cases, each taking a long time, the run time can be shortened by dividing that file into multiple files for more refined testing.
Combining and reducing redundant and complex tests can kill off the overall run time of the test suite. For developers, that’s a significant DX improvement.
Finally, one more way to improve developer experience is to optimize performance and workflow by embracing a Marie Kondo approach to development.
Marie Kondo, the author of the mega-bestselling book and TV show The Life Changing Magic of Tidying Up, advises her fans to ask if an object sparks joy before deciding whether or not to keep it in the home. If an object sparks joy, keep it. If an object does not spark joy, it’s donated, sold, or thrown away.
Taking a Marie Kondo approach to the SDLC could also be the key to unlocking more developer happiness, productivity, and positivity at work.
As code becomes more complex, testing must also become more complex to keep up. But, that doesn’t necessarily mean more tests are needed to maintain a project. Too often, piling on tests is equated with a higher level of security.
In reality, it’s about maintaining the tests that matter the most. Or, in Kondo-speak, it’s about keeping the tests that spark the most joy by delivering the biggest, most critical results.
There’s no need to collect tests, merely to create a shield of false security. Keep what matters when it comes to testing and ditch the rest.
Launchable is dedicated to improving developer experience through data-driven pipelines and faster, smarter testing.
Schedule your free demo of Launchable right here, right now.
If you’re ready to dive deeper into ways to improve Developer Experience, check out Launchable’s on-demand webinar.