There are two primary—and complementary—approaches to improving developer productivity. Both aim to use resources more efficiently and help ship code faster, while improving the developer experience.
Developer Productivity Management (DPM) focuses on the people, and answers questions like, “How can we get more output out of individual developers and teams by defining and tracking the right metrics?” Such metrics typically help to quantify output, evaluate performance and competencies, build and manage teams, and optimize collaboration and time management.

Developer Productivity Engineering (DPE) focuses on the process and technology, and answers questions like, “How can we make feedback cycles faster using acceleration technologies to speed up builds and tests?” and “How can we make troubleshooting easier, faster, and more efficient using data analytics?”

Our most recent blog post surveys the relative advantages and disadvantages of DPM and DPE, while ultimately recommending a DPE-first approach.

One of our customers noticed that their test lab and deployments had been failing more often but did not know why. So, they searched the Build Failures Analytics dashboard for the error message. It showed that over 8% of their builds were failing due to an issue related to publishing Docker images.

Armed with the evidence that the problem was severe and knowing exactly when it started, using Gradle Enterprise Build Scans the developer productivity engineers were able to quickly track down the root cause. Because they acted proactively rather than being caught off guard, when developers predictably started to complain they were able to tell them it was a known issue that was actively being worked.

When the issue was resolved they sent a report to all the stakeholders that showed when the problem started, when it was fixed, how many people were affected, and what steps were being taken to avoid similar incidents in the future. Ultimately the proactive response to this problem led to increased trust between developers, their tooling, and the developer productivity engineers supporting that tooling.

Check out this new video on Build Failure Analytics to see two more examples of how trust can be built by taking a proactive approach to identifying, prioritizing, and fixing problems within your toolchain.

Gradle Enterprise 2020.4 is now available and includes several highly-anticipated features. Here are the highlights:

Correlation and analysis of similar build failures
Build Scans now detect how many other builds failed with similar causes in the last 7 days, providing an important signal as to whether a problem is isolated or widespread.

More efficient test failure analysis
The Tests Dashboard identifies and highlights the most flaky or frequently failing tests across builds, making prioritization and analysis of test reliability problems more proactive and data driven. The new ability to display test failure messages in the test history view makes analysis of root cause differences more efficient.

Reduced disruption of distributed testing infrastructure faults
Prior to this release, network faults and other system failures involving distributed testing infrastructure and builds were likely to cause the build to fail. Now, Gradle Enterprise avoids build failure and significant disruption by rescheduling work and reallocating resources in response to this type of failure.

More convenient administration and configuration
Gradle Enterprise administration and configuration has become more convenient as it can now be done via its own web interface using its own access controls.

On November 19, you can learn how to reduce your Maven build and test times ~90% leveraging acceleration technology available in Gradle Enterprise. Topics include Build Cache basics, architecture considerations, task requirements, and best practices for using Gradle Enterprise to manage, analyze, and troubleshoot your Build Cache.

This is a 3-hour training session followed by a 30-minute Q&A. This course assumes a good understanding of the Java language and working knowledge of the Gradle Build Tool. After this training participants will be able to:

• Understand the benefits of using the Maven Build Cache
• Use and configure the Build Cache
• Optimize build logic for maximum cacheability
• Maximize the benefits of the Build Cache with Gradle Enterprise

• November 10, 9:00 am PT (2.5 hours): Hands-On Workshop: Introduction to Developer Productivity Engineering
• November 17-18, 8:30 am PT (4 hours): Introduction to Gradle
• November 19, 9:00 am PT (2.5 hours): Hands-on Workshop: Maven Build Cache Deep Dive
• December 17, 9:00 am PT (2.5 hours): Hands-on Workshop: Gradle Build Cache Deep Dive

Until next time!

- The Gradle Team