One Developer Experience - Build, Deploy, and Experiment: The Importance of Experimentation for DX

Experimentation has been around in the business world for a long time. From credit card vendors changing credit rules for certain cards to the placement of goods in retail stores, experimentation in business is to be expected. However, because of previous pain or fear of deploying and potentially having an unbound blast radius (e.g. impacting all users), experimentation with production traffic/users might take fairly long cycles in the development world - and sometimes altogether be avoided. 

The ability to experiment goes hand in hand with the ability to quickly iterate. Core to innovation work is to iterate, adjust, and optimize. Without having data from different renditions or experiments, improvements can turn into guesswork. As a developer, the experience around experimenting in a local or development environment is great because of the speed of implementation and limited blast radius of the changes/experiments. Though, to get actual production data and provide important feedback loops, feature flags are key to supporting DX in experimentation. The ability to experiment might not fit with the UX mappings to DX, but more of an intrinsic experience with more ability to help shape and mold product direction, for example.

This article contains an excerpt from our eBook, One Developer Experience - Build, Deploy, and Experiment. If you like the content you see, stick around to the end where we’ll link the full eBook for you. It’s free - and best of all, ungated.

Like the scientific method taught us, we need to be able to capture data and have a baseline/control when we run experiments. Having an idea of what is normal vs. regression for an application can actually be another challenge; going back, usually no one person works their entire career on one application.

This article contains an excerpt from our eBook, One Developer Experience - Build, Deploy, and Experiment. If you like the content you see, stick around to the end where we’ll link the full eBook for you. It’s free - and best of all, ungated.

Understanding Normality in Applications 

A common challenge for developers is having a clear picture of what is normal performance behavior for a distributed application. Going back to engineers being natural optimizers, when starting a project, a generic overarching goal of improving performance or stability is usually in the backlog in some shape or form. 

The question of “who owns the performance” of an application can be like playing a game of hot potato. Ranging from operations engineers to performance engineers down to the developers who wrote the feature, everyone has expertise to offer. From a developer’s perspective, unless the developer has production-facing or on-call responsibilities, disseminating this information can be tricky. 

Even in lower environments, when introducing a change, performance impact or regression can slip through the cracks until getting closer to production. The adage “slowness is the new down” is very true for internal and external customers alike. Disseminating information that was not easily unlocked before is core to the findability and credibility portions of Developer Experience. 

One of the last chasms to cross around Developer Experience supporting both the findability and credibility portions is solving for cost and density optimization.

Continuing On the Optimization Journey - Cost and Density

As systems grow more distributed, so do the lower environments that support distributed development and the increased flurry of iteration. It is a two-part problem to solve for. How does one optimize lower environments, and how does one optimize production environments? Providing functionality to assist in the optimization and dissemination of information fosters a better DX. 

Lower Environments 

One of the quintessential engineering jokes is that turning off is easy but turning back on is hard. Supporting development infrastructure and distributed environments can be quite costly. Shutting down resources on the flip side brings one more delay: eventually, developers will need to spin back up the resources. Because of advancements in compute and container technology, this could be slightly faster than years gone by. Development environments can consistently criss-cross distributed infrastructure to start back. The ability to autostop and also autostart workloads can help support the “what if I need it again” point of view. 

All Environments

Having clear and concise information on public cloud spend in how it pertains to specific applications and services can be an exercise in data aggregation and mathematical calculations. The ability to unlock and disseminate usage, density, and cost information pertaining to public cloud workloads allows for all engineers to make optimizations. Like modern paradigms around shifting left, developers will make the best decisions based on the data they have available to them. Typically, cost information would be locked away by finance orgs - but with these new FinOps methodologies, information is shared and optimizations are applied. 

The Harness Platform: One DX From Idea to Production and Back

The Harness Platform offers all of these pillars - and more - to help drive a positive Developer Experience from idea to production, and support as many of those iterative cycles to match the speed of development. 

Supporting great developer experience, your four key metrics from Accelerate (deployment frequency, lead time for changes, MTTR, and change failure rate) can all improve.

Conclusion

Developer Experience is key to building and maintaining the next generation of software and platforms. As technology proliferates our lives, your external customers do not care how features reach production. However, your internal customers are the source of those features and improving their experience will improve and nurture the innovation pipeline. As engineers in industry continue to move around to increase their skill and craft, having engineers become more productive in a shorter period of time fosters a culture of learning and innovation. 

We hope you enjoyed this final excerpt on experimentation of our One Developer Experience eBook. If you’d like to read the whole thing, go ahead and download the eBook today - it’s free and doesn’t require an email address: One Developer Experience.