Ideas & Insights

The Link Between Fast Feedback Cycles and Developer Behavior Change

There are many important reasons to minimize feedback cycles across the software development and delivery lifecycle. One reason is the positive effects it has on desired engineering behaviors. This is particularly true in regard to software building and testing. Specifically, fast feedback cycles encourage positive behaviors that may result in (1) increased individual developer productivity, (2) increased team efficiency, and (3) better quality software.

The relationship between the effects of faster feedback cycles on behavior (e.g. less context switching and building and testing earlier and more often) and the three benefits of those behavioral changes enumerated above is complex. There are some obvious direct impacts that faster feedback cycles have in encouraging and reinforcing good habits and developer best practices. However, a new Blog article has untangled the cause and effect relationship with other indirect benefits you may have not considered.

Expert Takes

Is it Time to Establish a Dedicated DevProdEng Team?

For most organizations, DPE should no longer be viewed as an informal, reactive, and opportunistic job to be done by developers in their spare time. Forward-thinking engineering teams have discovered that (1) systemic developer productivity gains require organizational focus, (2) the business case for forming a dedicated DPE team is a no-brainer, and (3) the reward for taking action is a sustainable competitive advantage. That is why many high-profile Dev organizations have long ago established dedicated DPE teams.

These business drivers are elaborated upon in a recent Blog post entitled: Top 3 Reasons to Launch a Dedicated Developer Productivity Engineering Team. You can also check out a video discussion on this topic with a couple DPE experts: Mark Vieira, senior software engineer at Elastic (NYSE: ESTC), who leads the dedicated DPE team, and Hans Dockter, founder and CEO of Gradle, Inc.

New Technology

Dependency Visualization for Maven

As discussed in a recent blog post Solving Maven Dependency Issues with Build Scans, dependency issues are frustrating. The rules are complex and without the right data, determining exactly what caused the issue can take time and energy. The new dependency visualization feature in build scans can help. A build scan is a powerful debugging tool that displays actionable insights for both local and CI builds all in one report.

The new Dependencies view in build scans for Maven provides users a graphical representation of the resolved dependency graph including transitive dependencies. The searchable list shows version conflicts, dependency types, and other information you don’t get from the command line. For changes between builds, the build comparisons show exactly which dependencies changed. If you aren’t already using Gradle Enterprise, you can try this out with the free-to-use scans.gradle.com service which provides some of the features of Gradle Enterprise.

Success Stories

Cutting Open Source Project Build Times 77%

The Gradle team evaluated the Maven build cache with a wide range of popular open source projects both small and large. Most projects, including small ones, can expect a significant benefit from the cache. In general, the better your build is modularized the more effective the cache will work for you. For example, if there’s only one module every change requires everything to be recompiled and all tests to be executed again.

While the Spring Boot project has since migrated to the Gradle build tool, it’s instructive for Maven users to look back at the results of a Spring Boot project build cache analysis described in detail here. At the time, the Spring Boot project total build time—with 1154 goals executed within 88 projects—took 17:32 (with build cache enabled 231 goals were stored in cache, but not executed). The second build took only 3:51 with 230 goals loaded from cache. Thus, running the second build without any changes, isolated an unstable input that could now easily be fixed. In another scenario that shows what can be expected when making small changes to a subproject that changes often, the overall build time was 4:42.

If you want to learn more about how build caching can impact your build performance with Maven, checkout our May 18 (9:00-12:30 PT) workshop. Topics include build cache basics, goal requirements, best practices, troubleshooting and more.

Featured Upcoming Event

CloudBees Connect Virtual Event: Next Practices for Improving the Dev Experience

In this introductory level presentation and training led by Gradle (May 19 - N. America; May 20 - EMEA), we will describe and demonstrate practical DPE use cases in action—taking examples from Java projects that rely on Maven or Gradle build tools. Specifically, you will learn how to:

• Leverage build and test acceleration technologies like build caching and distributed testing to instantly speed up feedback cycles as much as 90%.
• Cut debugging and troubleshooting time in half using data analytics to rapidly identify incident root causes and better manage avoidable failures like flaky tests.
• Continuously improve performance and guard against regressions through metric, KPI and trend observability.

The end-result of pursuing DPE excellence will be a transformative and highly satisfying developer experience. To join, register for the CloudBees Connect Virtual Summit.

More Upcoming Events

Don’t Miss these Opportunities to Learn More