60 to 100 days to onboard a developer - Highlights from the Harness State of Developer Experience survey

Plus, fun and strange finds from the World Wide Web

Today’s survey: “State of the Developer Experience 2024,” Harness/Wakefield Research.

Most enterprises need to automate their build and deployment pipelines. This is more than just building code and automating tests (which 71% of people are not doing), but also automating governance and security checks (which 41% of developers are not doing).

In my mind, this is the number one thing development organizations should be working on in 2024, and probably next year. Any ambitions to migrate to cloud, put Kubernetes in place, help software eat the world, etc. are going to go poorly if you don’t have an automated build.

Just automating your build will have large, positive benefits and ROI. Automating your build will give you a massive boost in productivity, meeting deadlines, meeting compliance and securing your apps, and raising employee morale.

A cynical(?) take on this is to say that the real magic of any “platform” or “cloud native” technology is that it requires you to automate your build pipeline¹ and that automating the build pipeline is where the majority of improvements come from. Whether you’re running your apps on VMs, Kubernetes, Cloud Foundry, a shell-script platform, or a bunch of raspberry pies duct-taped together, as long as the build pipeline is automated, you’re going to improve.

Let’s look at a recent developer experience survey that gives us more numbers to pile on that fire, the Harness “State of the Developer Experience 2024” survey.

Slow onboarding, slow releases, slow governance & security

• There’s very little demographics-wise, just that it was “500 engineering leaders and practitioners.” It was done with Wakefield Research.

• Developer onboarding time is a major focus, see below for longer discussion.

• “62% of executive buyers would prefer a platform versus siloed tools.” // I assume this means a centralized/standardized platform versus a bunch of platforms in silos, and then just tools that are not even integrated into a platform.

• “60% of organizations are still releasing code on a monthly or quarterly basis.” // In the 2024 CD Foundation survey, 40% of respondents said “less frequently than a month,” 31% said “once per a week to once per month.” Let’s take 10% from that 31% as “once a month,” and throw it together with that 40%, to get a delicious kapsalon of 50%. So, while the CD Foundation doesn’t capture “a month or more,” in the realm of sponsored surveys, the numbers are similar enough to be in the same ballpark.

• “67% of developers have attested to waiting over a week to complete code reviews.” And: “59% say that their AppSec requirements limit their ability to release code frequently.” // These isn’t the best proxy for bad bureaucracy, but they’re probably representative of governance bottlenecks. Now, if you got sloppy with code and security reviews, and something went bad in production, you’d probably be all for bottlenecking. And, in fact, that probably happened several times and it’s why you have those code review and security bottlenecks.

• But: “40% of developers admitted that their organizations don’t enforce good security and governance policies across the lifecycle.” // Optimistic case: that’s because they need to automate and standardize how security is done, which is now done manually, driving 59% of developers to say that security requirements slow down their release frequency. And, indeed: “41% of developers don’t have automated security and governance policies”…I assume that means “in place.”²

• These code and security review bottleneck figures are a good pairing with paired programming which has an implicit code review built in, more or less.

• Human stuff: “52% of developers cited burnout as a reason their developer peers leave their job.” And: “As evidence, 45% of developers surveyed say they don’t have enough time for learning and development. And executives seem to agree.”

• Global developer population estimate: “developers, estimated at around 30 million globally.” // This number is a lot harder to pin down than you’d think, so it’s always nice to see someone take a go.

Onboarding

“It would take a new developer 100 days to onboard, considering the multitude of tools involved.” Meanwhile, the executive perception is that it’s 40% faster: “71% of of executive buyers said that onboarding new developers takes at least 2 months [60 days].” It’s always fun to find differing perceptions between management and workers. Most of the mismatches are like this, with the management thinking things are better.

Solving this onboarding problem was the reason Spotify made Backstage, I think. That’s lingered in the platform engineering community ever since, though I see it a lot less now-a-days.

Relative to other problems, I’m not sure enterprises care that much about developer onboarding. It’s sort of a one time problem per developer. In tech companies, there’s high churn for developers, so you want to onboard people quickly to replace developers who’ve left, but also scale-up your efforts by hiring new developers as you write new code to add new features to grow revenue (or, eyeballs - whatever) and to get into new markets with new apps.

But I suspect that in not-tech enterprises, the churn is less. And, post-ZIRP/whatever, with the miasma of industry layoffs still lingering, I’d wager most buyers are less concerned with that. “What? Are they going to be able to find a new job? Back into the coal mines!”

STILL! It’s still a good tracer for software hygiene. One thing that’s overlooked in onboarding bottlenecks is the effect slow onboarding has on maintenance and bug fixing. When you go to fix a bug in production, you have to set aside the yet-to-be-released version of the app you’re working on, and go back and setup the old version of the code.

This means, basically, onboarding to the project again (OK, not all of it, but probably the majority of it), which is time consuming. So much so that many developers will keep those old versions all pre-installed and ready to debug and patch sitting around somewhere.

The business case for the elusive platform buyer

Marketing wise, they’re doing the “show ROI by increasing developer productivity” thing. This is a fine sales tool. Some clever sales engineer will create a spreadsheet of it, and you’re off to the races! Give it to an inside sales rep, and you’ve got some great email threads goin'. There’s always the dream of doing a self-service workflow where people fill this out themselves, see some cool bouncing charts, and then get asked if they want to talk with an ISR. (Does that actually ever work, though?)

That sells the idea of the problem you’re solving. What you have to marry that kind of ROI model with is showing that cheaper-to-free alternatives (“the developers say they can get Backstage up and running on their own…”) will not get you the same result. In that way, an ROI pitch like this is great for introducing a new idea and market category (here, platforms/IDPs) because you’re just trying to convince people that it’s a problem they have with a known solution.

You can also see who these ROI pitches appeal to because they’re using a base of 1,000 developers in the calculations. That’s a pretty big company, which is fine. They’re the ones you want to sell centralized developer tools to. A larger company has bigger budgets and it’s a lot cheaper to sell to one group than a bunch of dev teams.

Nowadays, finding the platform customer that also has budget is tough. The VP of AppDev has little budget, but they have the need. And, of course, they have tons of app developers who are like “oh, I could do that in a weekend.” The VP of Infrastructure has tons of budget, but they don’t care about apps (usually by design and comp)…and the app people don’t want them to care. You can go to Line of Business people (“The Business”), but that’s not easy either, pretty much impossible.

That misalignment is one of the reasons there’s so much platform sprawl, and why you need to do this kind of ROI’ing. You’re trying to go against the very structure of the IT organization. You know, change the “culture.”

Selling a centralized platform is tough!³

Work smarter but keep working harder

Here, let me find my Marx hat to put on.

ROI is a way of showing buyers that your software is worth paying for. It makes your developers work faster, and therefore they can hit deadlines better, software eats the world, number go up, BUSINESS, BUSINESS, BUSINESS!

Abd then, you can have the workers do more work for the same pay! More work with the same. Buy low, sell high.

This is why “productivity” can be a let-down for workers. Better productivity should mean that you can go home early, work less. But, nope: you keep working.

A worker might be motivated to increase productivity to prevent (1) overtime (in the survey 23% of developers said they work overtime at least 10 days a month), and/or, (2) boredom and tedium.

These are great things for a worker to strive for! However, management has to make sure to actually keep those benefits in place. As you get more productive, management tends to want to do more and tackle on more complex things. The Share Price isn’t content with flat, reliable EBITA.

If the workers suddenly have free time, get them to do more work! Eventually, you’re back to working more overtime and introducing back in the tedium. “Now we need to figure out how to leverage AI! Oh, and what’s your sandwich order for tonight?”

Progress! The cycle continues.

For workers, the productivity metrics to track are (1) going home on time (2) eventually, going home early, (3) reducing bullshit work that could be automated or just eliminated entirely (“toil”), (4) more pay and benefits.

We should make a Backstage plugin for those.

Definitions

Finally, the survey has some good, concise definitions of common terms:

• Toil: “Developer toil can be characterized by repetitive, manual, and low- value tasks that consume significant time and effort.”

• Goals of DevOps: “The overarching goal of DevOps is to foster collaboration, automation, and a continuous delivery pipeline that enables organizations to rapidly and reliably release high-quality software products and services.”

Reader letters

Jay Cuthrell sends the following re: yesterday’s ketchup taboos talk:

Two spouts - way to increase productivty, eh?

Check out his newsletter, if you like this one, you’ll probably like that one.

Relative to your interests

• Before Platform Engineering Killed DevOps, SRE Killed DevOps.

• That time when Microsoft bought and killed Nokia phone unit - Good write-up of (probably mostly) forgotten time. // “Barely two years after it was announced, the whole thing fell apart and Microsoft wrote the whole thing off as a tax loss.” And: “Elop was right, but his solution wasn’t.” // “Disruption” is an easy word to say, but a very difficult one to solve. // And a D&D reference! “The Nokia board rolled the dice again on hiring another non-Suomi manager, Rajeev Suri, and this time hit a double D20 in D&D terms.” (Though, I’ve never heard of a “double d20,” but, sure, probably.)

• If you didn’t find it in the links above, this documentary on waste and burnout in corporate work is great. You’t thinking “that’s an hour, WTF?” But, really, just watch it, it’s good.

Wastebook

• "A certain amount of uncertainty." Here.

• “Today, a fathom equals six feet–quite an inconvenient number to use in your head, when trying to go back and forth between feet and fathoms.” // For some of us, all numbers are “quite and in convent number to use in your head.” Here.

• “refusenik” bruces.

• “pluralistic ignorance.” Yup.

• And: “I really felt that part when the lawyer said she wanted to get hit by a car just so that she wouldn’t go to work. Feel that most days, if not all.” Comment on Ibid.

Conferences, Events, etc.

Talks I’m giving, places I’ll be, and other plans.

Atlanta Executive Dinner on Enterprise Software Dev, etc., May 22nd. DevOpsDays Amsterdam, June 20th, speaking. NDC Oslo, speaking, June 12th. SpringOne/VMware Explore US, August 26–29, 2024. SREday London 2024, September 19th to 20th.

Discounts. Cloud Foundry Day (May 15th): 20% off with the code CFNA24VMW20. SREDay London (Sep 19th to 20th) when you 20% off with the code SRE20DAY.

🪵 Logoff

I saw an early summary of a platform survey we just did. It has some good figures in there. I’m interested in sharing the platform sprawl related ones.

1. Your "path to production," your "secure software supply chain," your "CI/CD"...whatever you want to call it.

2. You could have a policy, I guess, in like some virtual three ring binders on Sharepoint, but not actually put it in place, but that seems even more Brazil than most G2000 could achieve.

3. And for all you super-nerd marketers following at home, notice that they don’t even have lead-gen! They have a scroll-over-a-gorge CTA to register for their online conference, which might actually convert pretty well? This kind of survey is probably also good for webinar sign-ups. But the lack of a “fill out this form a meeting” [which they have on the home page] is buck-wild!