On Thursday, January 28, 2021 (9am SF, 12pm NY, 5pm London, 6pm Berlin) we are excited to launch the first live episode of DevProdEng Showdown. DevProdEng Showdown is a series of live-streamed 30-minute events where a panel of distinguished experts debate hot topics related to Developer Productivity Engineering and Software Engineering at scale in a rapid-fire game show-like format. This episode’s topic is how to best develop for the JVM at scale in the enterprise.

This episode’s All-Star panelists are: Jinjing Duan (Airbnb); Kyle Moore (LinkedIn); Roberto Perez Alcolea (Netflix); and Hans Dockter (Gradle).

Topics of debate:

• Which programming language should be crowned the king when it comes to productivity and scalability? 
• Should IntelliJ be crowned the GOAT for productivity?
• How much build time pain should you be able to tolerate before you need a serious DevProd intervention?
• Once and for all, flaky tests should fail builds: yes or no?
• What did the COVID-19 and WFH experiment teach us about developer DevProd? 
• Even if we could reliably measure individual developer productivity, should we?

So take a break, have fun, learn something new, and be an active participant by voting for the contestants who make the best points and upvoting your favorite bonus topics. We will live stream on Twitch, YouTube and Facebook, but you must register to participate.

If some of the most important open source projects in the world are any indication, Gradle Enterprise is quickly emerging as a staple for build and test data analytics and as a source of acceleration technology for both Gradle and Maven-based builds. Spring, JetBrains (Kotlin), JUnit, and not surprisingly, Gradle Build Tool, all rely on Gradle Enterprise to improve build and test feedback cycle times and make troubleshooting more efficient with root cause analysis data (Build Scans) and failure analytics. 

In our most recent blog post, we provide a summary of the role Gradle Enterprise is playing in each project and some high-level results. Direct links to the public instance of Gradle Enterprise is provided for each project so you can check out the results in real time.

An affirmative answer to this question is the basis for Developer Productivity Management (DPM): the practice of using  developer productivity metrics to help to quantify individual developer and team output, evaluate performance and competencies, build and manage teams, and optimize collaboration and time management. 

We explored this question in our November Blog: Exploring the Developer Productivity Solution Landscape and concluded that while DPM and Developer Productivity Management (DPE) are complementary and not competing approaches to improving developer productivity, a DPE-first approach makes the most sense. Since then, we came across this concurring opinion from Charity Major in one of her CHARITY.WTF posts this summer. 

“I don’t think you can measure the “productivity” of a creative professional by assigning metrics to their behaviors or process markers, and I think that attempting to derive or inflict such metrics can inflict a lot of damage. In fact, I would say that to the extent you can reduce a job to a set of metrics, that job can be automated away. Metrics are for easy problems — discrete, self-contained, well-understood problems. The more challenging and novel a problem, the less reliable these metrics will be.”

We think you will find Charity’s rejection of DPM thought-provoking if not predictably entertaining given her inimitable “direct” style of communication. 

In 2020 COVID sent us home. This event produced a completely different scenario in companies where employees enjoyed fast corporate networks. The optimization in the Build System of teams working remotely has an impact on the speed and productivity of the engineers. Learn how Tinder leveraged build caching strategies to optimize the build speed in this recent .droidcon Americas presentation led by Inaki Villar, Build Engineer at Tinder.

Inaki explains that while simply enabling remote caching can significantly improve feedback cycles out of the box, Tinder went beyond its initial basic setup to provide even more dramatic results. Tinder initially experienced 13m42s builds with 99% cache hits. After further optimization they achieved 100% cache hits. This single percent increase, however, resulted in build times averaging 3m, representing a ~4.5X improvement. Inaki demonstrates how they used Build Scan root cause analysis data and the Build Scans comparison feature to investigate cache misses and resolve other cache configuration problems on route to this remarkable result.

• January 12, 9:00 am PT (2.5 hours): Hands-On Workshop: Introduction to Developer Productivity Engineering
• January 21, 9:00 am PT (2.5 hours): Hands-on Workshop: Maven Build Cache Deep Dive
• January 25-26, 8:30 am - 12:30 PT (8.0 hours): Introduction Gradle
• January 28, 9:00 am PT (0.5 hours): Developer Productivity Engineering Showdown | S1E1
• February 17, 9:00 am PT (2.5 hours): Hands-on Workshop: Gradle Build Cache Deep Dive
• March 23-24, 8:30 am - 12:30 PT (8.0 hours): Introduction Gradle

Until next time!

- The Gradle Team