What is typical loss of developer productivity due to issues with third-party tools and libraries?

I do not have a direct answer, but I have a good insight for you - it might be mostly-equally-good for your needs.

You need to achieve X. You have 2 possibilities:

1. Use an existing tool ("toolchains, SDKs, servers and libraries"). Spend some time for its integration, trainings for its usage etc.
2. Create the similar tool yourself. After it is implemented, integrate it, provide trainings etc.

I think that option 1 is usually more attractive than option 2. Option 2 is preferable to option 1 only if any of the following:

1. The tool does not exist.
2. The tool is prohibitively expensive, and you do not need all the features anyway.
3. The tool is likely to be abandoned in the useful feature (while you and your customers need to use that tool).
4. The existing tools have licenses which are incompatible with your needs.
5. Others.

This is not a comprehensive analysis, but a heads-up of the overall picture.

in every (two week) sprint or two ... incorporation ...

It seems that your project is quite badly organized, if you never foresee what you need or want.

at least one developer can easily lose on average a day or two struggling with the incorporation or use of a new tool, library, server program or similar

You write "lose". I read "use". It is a loss only if the endeavor is a complete failure. You do not "lose" time eating, you "use" time eating. The time used has a purpose, so it is not "lost".

A day or two throughout the life of a project (which can take months or years) is pretty much nothing. It happened to me that I used (literally) months to fully understand and to be able to use a certain library.

in every (two week) sprint or two ... incorporation ...

So every four weeks (or even more often) you incorporate something new external. It means that you integrate 13 (or more) new external things to your project every year. That is huge. So we go back to the original discussion - analyze your project and see if you chose the better way.

Not really an answer for the question as asked, but a mind frame challenge. The question "are there studies" feels less helpful as "how should I deal with that?"

1. Tools are an investment (even if they are free to buy/use). You need to setup the required infrastructure, have an update strategy, customize for your needs, setup guidelines for "best practices", migration plans, etc.
2. Tools require constant ongoing maintenance. Updates, bug fixes, new users, tech support new project types, new features, etc.

You should treat tool selection like any other business decision. Identify the setup and maintenance resources required and do a cost/benefit analysis. Work in the required setup and maintenance resources into your project plans and track over time to refine.

That's why for many companies tool selection is a strategic decision. You look at your requirements over the next few years and not just at a single project. For major tools you can setup dedicated resources for deployment and support. In any case, it's often a good idea to set some resources aside to have one or more "local experts" or "owners" who should be the first contact for the other developers and who setup knowledge bases and company specific "best practices".

This is no different from any other commercial tools: you need resources and infrastructure to sharpen your saw blades, keep your vehicles running, make sure your injection molding machines run at the correct pressure, etc.

This is very frustrating given that our industry narrative is that if software components exist they work well enough and can be easily combined to deliver features very rapidly.

But how extremely are you interpreting "easily" and "rapidly"?

The truly simpler and more routine things are, the more likely they are to be done by the computer itself, or at least by cheap clerks and third-world workers - the employed developer is only ever getting the ratty, complicated slice of the work that can't be routinised, and must involve a certain minimum of delay and difficulty.

are there any studies or surveys on this topic that can give me an idea on how much developers generally struggle with this?

I think what you're describing is potentially just the reality of development work.

If you innovate the tooling weekly or have lots of staff on a constant merry-go-round of different tools, then you're going to have to allow time for learning and (re-)habituation, the exact details and amount of which would depend heavily on the circumstances.

And bearing in mind that people can't learn new things for 8 hours a day.

In principle, you control excessive amounts of learning and habituation time by designing an appropriate job division. So you don't move the butcher, baker, and candle-stick maker around every day, shuffling between their very different machinery, techniques, and products.

But if you have to move people around, then the overheads you're describing sound very par for the course.

I want to know how much time they lose on other people's work.

What does that even mean? Almost everything is other people's work. Turning the key in the door lock is someone else's work. A developer will usually be operating computer technologies they have not assembled from the breadboard level (let alone the minerals that go into manufacturing the basic hardware), and are merely integrating the workings of software components and facilities together. That is the real job of almost all developers, and always has been.

The challenge is to understand the elements well enough to integrate them together in a suitable way, and learning about how those elements work (whatever they are in a particular case) is bread-and-butter software development work, not peripheral overhead.

I find conversations about developer productivity tedious. If you want to improve developer productivity, reduce or eliminate repetitive, needless tasks that serve no purpose.

3rd party tools, what exactly does that mean? The third party is to whom or what exactly?

I observe empirically that in every (two weeks) sprint or two at least One developer can easily lose on average a day or two struggling with The incorporation or use of a new tool, library, server program or similar.

If that server, library, or tool is necessary to the tech stack then so be it.

I really do mean that the developer loses time dealing with the artefact not working quite as advertised.

It is true, things break or don't work like you want them to work. Programming is a continual cycle of making code, breaking code, and fixing code. It is very unlikely that a piece of code that is even just somewhat complex is going to be correct the first time you write it.

Just like the Stephen King book you end up reading is not the book that was written in the 1st revision of the text.

This is very frustrating given that our industry narrative is that if Software components exist they work well enough and can be easily combined to deliver features very rapidly.

Is this industry narrative led by people who have written a single line of code in their lives? I guess it can be true that you deliver features rapidly in a tech team of a large size but software development is not an easy or quick process. I don't know why the people proposing this narrative would think so.

My concrete question is simple: are there any studies or surveys on This topic can give me an idea of how much developers generally Struggle with this?

All of software development is a struggle. All the tech jobs are a struggle. The reason why the profession is generally well paid is because it is hard and a struggle that not many people are willing or able to do.

I want to know how much time they lose on other people's work. The The reason I am asking is that this kind of information would allow me to prove the value of mitigating measures (such as support contracts or more conservative project timelines) more easily and would allow me to plan better.

If the deadline is the important part then you are either going to employ more people to do the work or move the deadline. The amount of pressure that your programmers are under is going to be known by your team leads. If they request more workers then you should consider hiring more.

Instead of having a pissing contest about whether your programmers spend 3 hours a week more learning a new web server have an honest conversation on whether your people are swamped and help them by reducing their workloads.

You don't need some study to tell you this. Talk to your people. Ask them if they think the deadlines are BS and just do what they ask.

I believe one developer struggling to incorporate or use a new tool is the norm of what I attest in multiple companies:

• Software integration seems to have expand a lot during the last decade with mobile, IoT, enterprises merges, acquisitions and partnerships.

• Expectations from IT have increased, also increasing complexity: more features, improved accuracy, real time response time, enhanced security, solution adapted for multiple platforms.

• More complexity create subdomains like front-end, back-end, devops, security, ai, etc.

• I feel organization start to accumulate legacy software faster with the employees turn around, new technology introductions (even some overlaps resulting debate like X vs Y), situation where the RoI need to be demonstrated to the stakeholders by scarifying maintainability like hyper-grow investment, market opportunity grab, company acquisitions.

You can have a master in .NET/Java/Whatever in your team, as soon this person need to implemented something like OAUTH2, he will need to understand the security domain, the keywords, how this tool match your project. It can take a lot of time resulting multiple "try and error" learning, back for forth with other domain experts, reading documentation or diving into the library code and may ultimately switching to another tool more adapted for the requirements.

I live multiple time those situations where management tried to improve velocity and unfortunately, I did not found any winning strategy:

1) The management decided to do everything in-house:

• PRO: Every technical decisions fit our needs
• PRO: 100% of the feature were used
• CON: Development was costly
• CON: What ever we developed seems to be sub-bar of the industry standard
• CON: The ramp up of new team member was hard, it may have been easier to pick up a open source/paid tool to have a "known standard"
• CON: Team members in the end tried to avoid to be on those tasks/projects because they were not perceived good for their career path

2) The management decided to partner with other companies

• PRO: Great support
• PRO: Able to suggest changes that was implemented a few sprint later
• CON: Politics between organization reduced our velopcity
• CON: Sometime what was delivered what more useful for them or their customers than us

3) The management decided to integrated paid 3rd party and sometime pay for new features:

• PRO: Faster velocity
• PRO: Can be industry standard or better quality, they know the domain
• PRO: Can pay for support or consultancy
• CON: Can be very very very costly
• CON: Sometime the 3rd party have other priority that does not match your organization

4) The management decided to integrated open source

• PRO: You can recruit or contract people that are contributing on those projects
• PRO: They are often base on a standard
• PRO: Free, cost and source code
• PRO: Support from open and larger communities
• CON: Sometime the licensing that mandate you to share also your code you work on it
• CON: I discovered that a lot of open projects, even popular one, seems to be maintained by a few peoples, sometime, those projects are almost hibernating, no more improvement depending of those people personal and professional life
• CON: There are a lot of communities that have in-fighting, creating fork of the same projects, splitting the community, at those moment, there is also less improvement
• CON: Dependency hell: upgrading can be painful to figure out the compatibility between dependencies, not every components follow the same version scheme and sometime components are deprecated, make it hard to move on

I am not aware of any studies on the time to generally integrate third-party tools. Even if they existed, I think the validity would be low when applied to any particular tool/project/team combination. For example, it's one thing to use a string-processing or math library in an existing project, and something else entirely to build an application on ArcGIS or the iOS SDK. I could make a case that both extremes would fall under the umbrella of using third-party tools.

Because this sounds like an ongoing issue, I would guess that you already have excellent empirical data about the effects of this on your teams for the kinds of work you do. It's probably stuck in Jira somewhere, but you have it. If you don't, you can start tracking it.

To understand the effect of this on your team, start looking at cycle time.

Even better if you can track cycle time for tasks that involve integrating third-party tools (via a tag in Jira or similar).

Because integrating the tool and working through its quirks is part of doing the task, I wouldn't break out a separate task for quirk-handling. For example, if the task is "show a pretty graph to the user", and your team spends three days trying to get Chart.js to behave itself, those three days are all part of showing a pretty graph. (No separate task for "make Chart.js behave".)

Once you have cycle times, you can work to make improvements. The kinds of improvements, well, that's up to you. It might be trying to work faster. Or, better, when you approach sprint or project planning, you can look at actual data. "Let's see, we think we'll have four third-party integrations, current cycle time for integration tasks is running at 1 week per, so that's at least four weeks just for those integrations. Plus the five weeks we already estimated for our application work."

Over time you can get more detailed if you want (e.g., track cycle times separately for embedded work), but that's more than you want to start with.

Summary:

1. Get historical cycle times if you have them.
2. Begin tracking cycle times now.
3. Use cycle time data to improve your estimates.