Culture
Development leads often overlook data-related obstacles that impede developer experience and productivity, from manual test data provisioning to non-production environments containing sensitive data. Discover 3 proven approaches to liberating developers from mundane tasks.
Robert Henning and Todd Tucker
Jul 25, 2023
Share
Developer Experience (DX) refers to the overall experience and satisfaction of developers when doing their jobs (i.e., creating software applications). It encompasses the entire journey your developers take with your company, from the initial onboarding process to ongoing development, testing, and deployment of their software.
Managers working to improve DX often focus on providing developers with a seamless, efficient workflow and empowering them to be productive. One indirect measure of DX is the amount of time developers spend on writing code to other activities such as meetings, testing, documentation, bug fixing, and more. It is not uncommon for developers to spend the majority of their time on non-coding activities.
Why do business leaders care about DX? A positive developer experience promotes developer satisfaction, increases productivity, fosters innovation, and attracts and retains top developer talent. In other words, a good DX creates positive returns for the business.
In our experience, leaders often overlook several methods for improving DX and productivity. The most critically neglected of these are automating test data provisioning, reducing rework by shifting left quality, and eliminating sensitive data from development environments.
The provisioning and deprovisioning of test data within an organization is often a manual or poorly automated process. Often, database administrators (DBAs) must be involved to deliver test data; they may have scripts or other tools but the task often takes a fair amount of their time. Depending on the compliance requirements, they must then mask or remove any sensitive data fields (e.g., personally identifiable information (PII), account numbers, etc.) before moving it to the proper development environment. As a result, fulfilling test data requests often takes days, weeks or months, during which developers must wait.
Automating data delivery dramatically reduces the effort and wait. Consider the experience of Mizuho Securities, a Japanese bank heavily invested in DevOps and continuous integration/continuous deployment (CI/CD). “We had five database administrators looking over 800 systems, so we expected that continuing manual masking would create a massive bottleneck for our offered development environment,” said Satoshi Ando, Mizuho Securities IT Infrastructure Management Department Chief. “We used to copy the data for a week after the request and then it took a day or two to mask it, so I think it’s a huge benefit that we can provide a development environment as quickly as possible. Our development team has been highly complimentary of our new approach”.
Mizuho Securities shrunk the time it took to deliver test data by 90%.
Analyst study of customers shows that the Delphix DevOps Data Platform delivers a 408% 3-year ROI. Discover the tangible benefits of Delphix, validated by IDC analysts.
A “shift-left” quality strategy refers to a proactive approach where quality assurance (QA) activities are performed beginning stages of the software development lifecycle (SDLC). This sort of strategy aims to detect and address quality issues as early as possible, reducing the cost and impact of defects that may make their way into production systems and improving overall software quality.
The DX-related danger of shifting left is that it may add to developers' workloads as they need to execute unit tests, participate in code reviews, and address quality-related issues. It may also require developers to acquire new skills and knowledge in QA practices, testing frameworks, and tools. But when shifting left is done right, it reduces the amount of rework that developers must perform.
Pitfalls to avoid when shifting left include failing to support developers with good test automation tools and scripts, providing poor quality test data to developers, overemphasizing test documentation during unit testing, and failing to foster collaboration between developers and QA teams.
The importance of providing high-quality test data to your developers should not be overlooked.
Compliance is a constant concern for developers. In the context of development, compliance refers to the processes and procedures to ensure that the software delivered is secure and adheres with policies and regulations such as GDPR, HIPAA and common standards like PCI DSS or ISO 27001:2022. However, it also includes compliance of the software development processes, tools and data.
When sensitive data is present in development environments, it raises the compliance bar for developers. In those situations, it is not uncommon to see the following procedures in place:
Privileged user management processes that require separate logins and extra auditing
Advanced security reviews for the creation of new environments
Periodic security reviews of existing development environments
Adherence to data classification guidelines, including security clearances for government agencies and contractors
Shorter timeouts on developer workstations with more frequent multi-factor logins
Tighter configurations of developer devices and restrictions on using personal equipment
Stricter requirements for remote work, including the use of VPNs to access cloud-based environments
Non-Production environments are the largest attack vector typically with the loosest security controls that both internal and external bad actors prey upon. By eliminating sensitive data from all non-production environments - an increasingly common strategy - many businesses are able to ease some of these restrictions, make the developer experience less onerous and significantly reduce the risk of sensitive data breaches.
Improving developer experience (DX) is crucial for business success, but businesses often overlook certain key methods for doing so. Automating test data provisioning, implementing a “shift left” strategy for quality, and eliminating data from development environments carries more benefits than just optimizing DX. These strategies also foster a positive development environment, and ultimately deliver higher-quality software with less developer effort. Prioritizing DX contributes to improved business outcomes by establishing a foundation for success in the ever-evolving software development landscape and makes the organization a better place to work too.