Admittedly, the path to successful PLG implementation has some challenges that can derail even the most promising companies. Specifically, the organizations that are transitioning from more traditional enterprise growth models may, in fact, have difficulty when navigating the change in dynamic – either from technology or leadership transitioning. As such, I’d like to explain three common missteps that organizations often encounter when adopting a PLG strategy and discuss how to overcome them. By understanding these pitfalls, organizations can better position themselves to harness the full potential of PLG and drive sustainable growth.

Before I dig in, it’s important to note that it’s a misconception that organizations need to choose a PLG or sales-led approach. In reality, there are companies that have succeeded by having both. It matters on who the customer is and what level of hybrid motion works for each company. For example, a product-led approach may not be well suited for organizations that rely heavily on an outbound sales motion. For organizations with a strong inbound sales motion, however, PLG can be a value add.

With that, I’ll dive into the missteps: 

1. Failing to Maintain a Product-Centric Culture

One of the most critical aspects of PLG is fostering a product-centric culture throughout the organization. This means aligning every department – from engineering and design, to marketing and sales – around the product’s value proposition and user experience. Many companies stumble by treating PLG as merely a go-to-market strategy rather than a holistic approach that permeates the entire organization. This misalignment can lead to inconsistent messaging, disjointed user experiences, and ultimately, a failure to deliver on the promise of PLG.

To succeed, companies should:

• Prioritize cross-functional collaboration and communication;
• Invest in continuous product education for all employees; and
• Empower teams to make data-driven decisions that enhance the product experience.

By fostering a genuine product-centric culture, organizations can ensure that every team member contributes to the overall PLG strategy, creating a cohesive and compelling user journey

2. Getting Distracted by Individual Customer Requests

In the pursuit of customer satisfaction, it’s easy to fall into the trap of catering to individual customer requests at the expense of the broader product vision. While customer feedback is invaluable, allowing it to dictate product direction entirely can lead to feature bloat and a diluted value proposition.

Successful PLG requires a delicate balance between addressing user needs and maintaining a focused product roadmap. To strike this balance:

• Develop a process for prioritizing feature requests based on their potential impact on the overall user base;
• Communicate transparently with customers about product decisions, features, and timelines; and
• Use data and user research to validate assumptions and guide product development.

By maintaining a clear product vision while remaining responsive to user feedback, companies can create a product that resonates with a broader audience and drives organic growth.

3. Struggling to Balance Stakeholder Needs with Product Vision

PLG doesn’t exist in a vacuum. While the product is the primary growth driver, other stakeholders – including investors, partners, and internal teams – often have their own goals and expectations. Balancing these diverse needs with the overarching product vision can be challenging.

Companies may falter by prioritizing short-term gains over long-term product health or by compromising on user experience to meet arbitrary growth targets. To navigate this challenge:

• Establish clear, measurable metrics that align with both product and business goals;
• Educate stakeholders on the principles and benefits of PLG to gain buy-in and support; and
• Regularly review and adjust the product roadmap to ensure it aligns with both user needs and business objectives.

By fostering alignment between stakeholder expectations and product vision, organizations can create a sustainable PLG strategy that drives both user satisfaction and business growth.

Beyond the Basics: Additional Considerations for PLG Success

While addressing these three common missteps is crucial, there are additional factors that can make or break a PLG strategy:

• Hiring for PLG expertise: Many organizations underestimate the importance of bringing in specialized talent with PLG experience. Look for individuals with a growth mindset and a track record of success in product-led environments, especially in SaaS.
• Investing in robust instrumentation: PLG demands a data-driven approach. Ensure you have the right tools and processes in place to collect, analyze, and act on user data effectively.
• Continuous optimization: Both your product and your acquisition funnel should be subject to ongoing refinement. Establish a culture of experimentation and iteration to drive continuous improvement. Additionally, a touch of customer obsession cannot hurt! Obsess over your customer experience and evaluate their journey through your product to inform experiments. By truly understanding your user’s journey, you can clearly see where customers encounter friction or obstacles. This allows you to proactively enhance these touchpoints, leading to a smoother and more satisfying experience. 
• Empowering marketing: While the product leads the way, marketing plays a crucial role in amplifying its reach. Equip your marketing team with the resources and autonomy they need to effectively drive the pipeline.

Product-led growth offers immense potential for SaaS companies looking to scale efficiently and deliver exceptional user experiences. By avoiding these common missteps and focusing on building a truly product-centric organization, companies can unlock the full power of PLG.

Successful PLG is not about perfection from day one. It’s about creating a culture of continuous learning, experimentation, and improvement. By staying true to the core principles of PLG while remaining flexible in its implementation, organizations can build products that not only meet user needs but also drive sustainable business growth.

The post 3 common missteps of product-led growth appeared first on SD Times.

So now, on top of all the other components a car needs to function, software is also now in the mix, creating a complex ecosystem that cannot fail at any point.

In the most recent episode of our podcast What the Dev, we were joined by Cameron van Orman, chief strategy & marketing officer and GM of Automotive Solutions at Planview, to talk about how these automakers are managing their software development life cycles.

Here is an edited and abridged version of that conversation: 

Let’s talk a little bit about the complexity in making these cars happen, the software. What goes into making these autonomous vehicles?

As you said, David, it’s very complex. You’re taking an industry that drove the Industrial Revolution and became experts over 100 years of mechanical, physical engineering, bending metal, combustion as part of vehicle propulsion. And now this same group that has this 100 years of physical supply chains is now coming a little bit late (but fast) to the party on software. Depending on which auto manufacturer you talk to, you have somewhere between 100 and 500 million lines of code in a current automobile — and I’m not just talking EVs. Even in a traditional internal combustion engine propelled car there’s a lot of complexity in all that software built and designed from not just the OEM, but a multi-tiered supply chain. How do you get all that integrated, working, and effective and delivering transformative experiences for us as drivers and passengers?

Building cars had always been a very mechanical kind of a process. Now it’s much more of a digital process in many ways. I mean, it’s the merger of both, actually. How are automakers adapting? 

It’s a complete change, arguably. I heard one of the world’s largest cloud infrastructure providers accuse the automobile industries of being the last stalwarts in adopting cloud, and many of them are still on-prem, yet they’re really adopting all this modern software so quickly. In the last 10 years, there’s just been this explosion of code and software in a car, but there’s still a challenge in this Agile transformation, digital transformation, that’s going on in an industry that has this deep heritage in physical manufacturing and bending metal. 

Launches of a new car platform or a new car model are often now dependent on software. Mark Fields — he’s the former CEO and chairman of Ford — is chairman of Planview, and so I’ve had the opportunity to talk at length with him on this topic. And over 100 years, auto manufacturers have really perfected and have this great visibility into everything physical that goes into the launch of a new vehicle, all the design and aero and compulsion and combustion and all the tooling of factories, but now it’s software that’s causing models to be delayed. In some cases, it’s causing executives — and we saw it over in Europe — to lose their jobs.

And unlike physical manufacturing with this long history and understanding of the burn down — you start with a gazillion items to do, and every week you have your meeting, and items just get reduced until it’s ready to launch — that’s not the way software development works. And auto companies are grappling with predictability and efficiency of their software supply chain, not just their physical supply chain. If software is late or is going to delay a launch of a platform, that can cost ten of millions of dollars, as you have physical plants that have been tooled up and sitting idle.

What about the testing of that software? Obviously, this has to be mission critical stuff. You can’t have a software defined vehicle have a failure, that would be catastrophic. So how does that work in terms of when you talk about portfolio planning, how much of the pre-planning has to go into it to ensure things like that aren’t happening? 

A lot. How do you have that visibility into the full life cycle effectiveness, flow, predictability and throughput of your software tool chain and software development processes. And what’s really unique about the auto industry is when we talk about technology buzzwords like DevOps or value stream management, most often we think about it in the confines of a single organization. But in automotive you’ve got to think about it across their distributed set of suppliers and companies, from the OEMs the tier ones to the tier twos. 

As a driver or passenger in an automobile you don’t know  — whether it’s the braking system or the infotainment center — was the software that manages it and runs it, was that built and coded by the OEM, by the tier one, by a sub component supplier? And you don’t care. It’s all got to work together. 

And so the complexity of your software development life cycle and the need for visibility is far greater. Single companies struggle with visibility across their DevOps or software life cycles across all the steps and tools. Magnify that by OEMs, who have their own divisions and regions and silos, and then they have their own complex configuration of suppliers that can number in the hundreds. You need that visibility. And you talked about quality. You need that traceability. 

As we were sort of preparing for the call you talked about your wife having issues with the infotainment system. So, you go to the local dealer or mechanic shop, and they’ve got to flag that IT software issue up to the OEM. The OEM has to figure out who really created that code, tier one, tier two, and it’s got to trace it all the way through to that development team. They’ve got to see it. They’ve got to then fix it, and it’s got to push it all the way back up and ultimately, into the car, right? And that traceability is so important.

The post Q&A: Developing software-defined vehicles appeared first on SD Times.

If you can generate five or even 10 times the amount of code you previously could, that’s also five to 10  times more code that needs to be tested. 

“Many CFOs right now are looking at $30 per month per developer to go get them a GitHub Copilot or similar product,” said Jim Scheibmeir, senior director analyst at Gartner. “And I feel like we’ve kind of forgotten that frequently a bottleneck in software development is not the writing of code, but the testing of code. We’re gonna make developers so much more productive, which includes making them more productive at writing defects.”

Unlike AI-assisted dev tools where developers want to write more code, the goal with AI-assisted testing tools is to enable less testing. For instance, according to Scheibmeir, things like test impact analysis tools can create a testing strategy that is properly sized for the actual code change that is being pushed, so that only the tests that need to be run are run, rather than just running every test you have for every change. 

“These tools provide focus for testers,” he said. “And it’s so very difficult to give testers focus today. There’s this feeling like we must go test all of the things and yet we’re always crunched on time.”

Arthur Hicken, chief evangelist at Parasoft, agrees that we’ve already reached a point where test suites are taking hours, or even days, to complete, and using generative AI to help optimize test coverage can help with that.  “You can put together with AI these days a pretty good estimation of what you need to do to validate a change,” he said.

Generative AI helping with test generation, management, and more

Beyond helping testers test less, AI is creeping into other aspects of the process to make it more efficient end to end. For instance, Madhup Mishra, SVP at SmartBear, says that generative AI can now be used to create the tests themselves. “The tester can actually express their software test in simple English, and AI can actually create the automated test on their behalf,” he said. 

“Behind the scenes, GenAI should be understanding the context of the test, understanding what’s happening on the screen, and they can actually come up with a recommended test that actually solves the user’s problem without the user having to do a lot more,” he said.

Scheibmeir explained that the idea of making test generation easier had already been explored by low-code and no-code tools with their intuitive drag-and-drop interfaces, and generative AI is now taking it to that next level. 

And according to Eli Lopian, CEO of Typemock, AI is really good at exploring edge cases and may come up with scenarios that a developer might have missed. He believes that it can understand complex interactions in the codebase that the tester might not see, which can result in better coverage. 

AI can also help with generation of test data, such as usernames, addresses, PIN codes, phone numbers, etc. According to Mishra, generating test data can often be a lengthy, time-consuming process because testers have to think up all the possible variations, such as the characters that can go in a name or the country codes that come before phone numbers. 

“Generative AI can create all the different combinations of test data that you can ultimately use to be able to test all the corner cases,” Mishra explained. 

Another potential opportunity is using AI in test management. Companies often have a repository of all the different tests they have created, and AI can sort through all that and make suggestions on which to use. This allows testers to utilize what they’ve already created and free up more of their time to create new tests they need, explained Mishra. 

Parasoft’s Hicken added that AI could sort through older tests and validate if they are still going to work. For instance, if a test is capturing today’s date, then that test won’t work tomorrow. 

AI might make testing more accessible, but won’t eliminate need for it

Together, all of these AI enhancements are helping organizations take more responsibility for software quality themselves, where in the past they might have outsourced testing, Scheibmeir said. 

Similar to the citizen developer movement, the capabilities for testing that are now available make it easier for anyone to run a test, so it doesn’t require such specialized skills like it once did. 

“The hype and capabilities that generative AI are offering have brought some of these organizations back to the table of should we own more of that testing ourselves, more of that test automation ourselves,” Scheibmeir said. 

However, it’s still important to keep in mind that AI does have its drawbacks. According to Lopian, one of the biggest downsides is that AI doesn’t understand the emotion that software is supposed to give you. 

“AI is going to find it difficult to understand when you’re testing something and you want to see, is the button in the right place so that the flow is good? I don’t think that AI would be as good as humans in that kind of area,” he said.

It’s also important to remember that AI won’t replace testers, and testers will still need to keep an eye on it for now to ensure all the right coverage and the right tests are happening. Lopian likened it to a “clever intern” that you still need to keep an eye on to make sure they’re doing things correctly. 

AI’s impact on development skills will drive need for quality to shift further left

Another important consideration is the potential that if developers rely too heavily on generative AI, their development skills might atrophy, Mishra cautioned. 

“How many times have you gotten an Uber and realized the Uber driver knows nothing about where you’re going, they’re just blindly following the direction of the GPS, right? So that’s going to happen to development, and QA needs to sort of come up to speed on making sure that quality is embedded right from the design phase, all the way to how that application code will behave in production and observing it,” he said.  

Hicken agrees, likening it to how no one memorizes phone numbers anymore because our phones can store it all. 

“If I was a young person wanting to have a good long-term career, I would be careful not to lean on this crutch too much,” he said.

This isn’t to say that developers will totally forget how to do their jobs and that in 20, 30 years no one will know how to create software without the help of AI, but rather that there will emerge a new class of “casual developers,” which will be different from citizen developers.

Hicken believes this will lead to a more stratified developer community where you’ve got the “OG coders” who know how the computer works and how to talk to it, and also casual developers who know how to ask the computer questions — prompt engineers. 

“I think we are going to have to better define the people that are creating and managing our software, with roles and titles that help us understand what they’re capable of,” he said. “Because if you just say software engineer, that person needs to actually understand the computer. And if you say developer, it might be that they don’t need to understand the computer.”

You may also like…

The evolution and future of AI-driven testing: Ensuring quality and addressing bias

RAG is the next exciting advancement for LLMs

The post Generative AI development requires a different approach to testing appeared first on SD Times.

While the change was challenging, having engineers in charge of product visioning ultimately led to better products being designed. That’s why this way of doing things has influenced the way countless startups founded by former SpaceX engineers have structured their engineering departments – including ours.

Are there challenges with setting up software development this way? Sometimes. Does every software engineer want to be in charge of product visioning? Probably not. It’s important for product visioning to be in the hands of engineers – and changes in the industry and software development tools themselves are compelling engineers to up level their skills in ways that lead to better products, and, in my mind, a better career.

From Ticket Taker to Extreme Ownership

Here at Sift, we don’t have product managers so the types of software engineers that we hope to attract are people who want to have total ownership over how our software is designed and what features go into it. SpaceX has an extreme ownership culture where people are given more responsibility and expected to grow into that role instead of being given a little box to work in. When you put people in boxes, you don’t allow them to realize their full potential. I think that’s why SpaceX has accomplished some pretty amazing things. In our effort to create similarly amazing technology, we are trying to also instill a culture of extreme ownership. How do we do this?

A lot of engineers are motivated by wanting to solve their customer’s problems – the question is how much do they feel that through the abstraction of a requirements document versus actually watching their customer use the software? We believe it is the latter, which is why we have our engineers work directly with customers as much as possible. 

This way of working is actually responsible for the original DNA of our product. When we started Sift, our small team sublet space from a company in our network who we knew could benefit from the product we were trying to develop. They shared their data and we set out to develop software that we knew could help them and countless other startups struggling with developing cutting edge hardware in a growing sea of data. We spent three months in their space, iterating our product. We brought the two engineering teams together to show them their data in our tool and had them use their existing solution and the one we were developing side-by-side. At the end of that period we had developed a product they were willing to pay for and one that is now helping a number of other startups solve similar problems.

While we don’t set up shop in our customers offices, we do get our engineers directly involved in new customer onboarding sessions – meeting face-to-face to see how customers work in their existing tool and watch them work in ours. This helps to make sure that our solution is set up in a way that is going to benefit them the most – and informs important product development decisions for the next iterations of our product. Engineers spend a lot of time in the tools they are developing so it’s not always easy for them to identify things that are missing in the product or areas where the product is clunkier than they should be – spending a day or two with a new or existing customer actually watching them use it is the perfect cure for that. This direct line of communication between our customers and our engineers continues long after the initial onboarding session through direct Slack channels that we set up and quarterly meetings with members from our engineering team. 

Engineering in a Post Chat GPT World

While this all sounds like a ‘nice to have’, I believe in a world where increasingly software is going to be written by low code applications and AI copilots, engineers need to level up. AI is going to take over more software development and it’s going to go after the simple things first. Engineers can do one of two things: focus on work that is deeply technical or develop a really deep understanding of how the tool is used, the industry it’s being developed for, and the problem it is trying to solve. 

We want our engineers to be part of the future, not stuck in an endless loop of ticket taking. Despite what the old tropes about engineers say, we are finding legions of engineers excited to welcome a new way of doing things – and that’s going to benefit customers and the engineering profession at the same time.

You may also like…

Developers, leaders disconnect on productivity, satisfaction

Prioritizing your developer experience roadmap

The post The secret to better products? Let engineers drive vision appeared first on SD Times.

Qodana is a static code analysis tool that integrates into JetBrains’ IDEs, allowing issues to be addressed directly within the IDE.

“Since launching the cloud version of Qodana last summer, we kept receiving requests for a self-hosted version. Following successful Beta tests with some of our clients, we’re now launching the first release of Qodana Self-Hosted, allowing you to manage, maintain, and upgrade Qodana entirely on your end,” JetBrains wrote in a blog post. 

Qodana Self-Hosted helps companies ensure that their proprietary or sensitive information stays within the company’s infrastructure, offers them greater control over data control and processing, and can have better performance due to the ability to optimize the solution to the organization’s specific performance needs. 

The self-hosted version currently only supports AWS, but JetBrains plans to add more hosting options in future versions. Pricing will start at $40 per developer per month, but organizations that request a demo by August 31, 2024 will receive a 40% discount off one year of Qodana Self-Hosted. 

Other recent improvements to Qodana include an early access program for the C and C++ linter, the ability to create custom inspections with FlexInspect, support for Unity analysis, and the addition of .NET analysis to the Community version.

You may also like…

JetBrains’ code quality platform Qodana reaches general availability

The importance of prevention: How shifting left, static analysis and unit testing create better code quality

The post JetBrains now allows Qodana to be self-hosted appeared first on SD Times.

To dig deep into why that’s happening at such a high rate, we invited the company’s CEO and co-founder, Andrew Lau, onto the latest episode of our podcast, What the Dev?

Here’s an abridged and edited version of that conversation.

Jenna Barron: What are some factors that have contributed to the percentage of burnout among developers being so high? 

Andrew Lau: I think it’s a compounding of a number of effects. First and foremost, I would just say it’s been a crazy four years. I mean, it’s been so volatile; you’ve got pandemics, you’ve got booms and busts. And so, like there’s a health crisis, first and foremost, and people are kind of getting through that. And there have been really huge economic swings in the tech industry. I think the broad economy seems to be doing okay, but if you look at the tech sector as a whole, it’s been hard. And that puts pressure on everybody around what that actually means for them. 

And I actually think that we are at a time where we’ve learned as a community, as an industry how to work remotely or hybrid. But I think those environments aren’t always the most conducive to actually making it a human experience or easier. For me, I go from Zoom to Zoom to Zoom without any breaks. And we haven’t learned the rhythms of keeping sanity in that. 

And then like the last layer on top is like we’re at a time where AI is already causing change, there’s looming change coming. And there’s a lot of unknown and pressure. 

I think it’s the backbone theme through all of this that is causing a lot of stress and inevitably leads to burnout.

JB: What do you think that companies and leadership can do to ensure that their employees don’t reach that point?

AL: Well, if everyone had a magic formula, we’d all just do it and be done. But I think in some ways, it is simple in the sense that we have to acknowledge it first. I think if you don’t say this is an issue and how we address it, then that’s a problem. You’re never going to fix it otherwise. 

So I think it’s important to ask and understand how your team is actually doing with respect to that. I do think though, one aspect of this is about why change is happening. And so some is clear, like pandemics you can’t control and hybrid happened to all of us in this way. But I think in some ways, we have to talk about the intentionality around some of this too. And just saying, like, “hey, this is happening and this is why we’re doing it.” I think that helps people understand the why, and often that can either make it easier to accept the changes that need to happen, or figure out better ways to do it.

JB:  Another finding from the report is that 90% of the respondents said that engineering teams are actually informing business strategy. So what does that look like in practice?

AL: This is, I think, an acknowledgment from that old Marc Andreesson statement that software is eating the world. I think we’re there and ate the world. 

Now, what does it actually mean? Well, it first meant that every company is actually making software. But more than that, that software is the manifestation of the company’s offerings now. And you see this in every industry, whether it’s healthcare or banking, or whatever it is, software is the lingua franca of the thing you’re making, or the thing that makes the thing you’re making. 

And so how does it look in practice? Well, if that’s true, then it means the ideas are coming from the teams. So I think you’re actually now starting to see this around AI innovation. Historically, someone might say, we ought to solve this business problem, okay. But now you have to ask yourself, what are the technical limitations? Can we even do that or not? Or, we have this AI thing, what are we going to do with it? And how does it actually manifest? It’s teams actually trying stuff out, plugging it in, etc. So whether it manifests in a hackathon or side projects, or people dealing with ChatGPT to try to go ahead and change something, it’s just manifesting very quickly. At the very least, it may not be a complete product yet, but at least it sets a direction and stage and unlocks the facility. And people are realizing what can and can’t be done. And it’s no longer like it can be a business decision alone. In fact, the innovation of spirit is coming from the technologists and the manifestations in that way.

JB: It seems kind of counter to what we’ve heard over the years where there’s been sort of like this friction between leaders and engineers, and engineers want to build one thing and the leaders want something else. And engineers are like, “No, we can’t do that.” But it seems like based on these numbers, the engineers are having more of a say in what’s realistic and what can be done.

AL: I think I’m with you. I think there’s actually a confluence of two forces going on there. One is that things are so novel and complicated, but also idea inspiring, so the manifestations can come from the engineers because they’re making it happen. It’s like everyone just suddenly gets it or they see competitors suddenly do this. So in some sense the medium is allowing the makers to actually suddenly blossom those ideas on the other side. I just led this conversation earlier, which is we’re in a time of economic uncertainty and potentially just like tough times in the tech space. Again, no one seeks it, but there are some silver linings to here, which is it forces alignment, like in the sense that when waste is prevalent, like both parties were like, “Well, I think we should be making this,” “I think we should be making that.” In a time where we’re focused on efficiency, you have to reconcile the two. It can’t be like, I wish this and I wish that. It’s like, no, we have time for one of those things. And we’re going to reconcile it. And so the confluence of those two forces, I think, allows some alignment to suddenly happen in that way.

JB: I know the report had a lot of other interesting things. And we really only covered two of them. What would you say is the biggest takeaway from the report, or maybe an interesting thing that we didn’t touch on that you would want developers and engineers to leave with? 

AL: Change is so deeply in play in our industry right now, and in every way, from the way we work, to the tools we use, the technologies, manifestations we can actually make. It’s happening at every single layer. 

And so with that, I actually think you have to have all parties fully embrace change. Like it is happening, you can’t fight it. Accept it and figure out how you’re going to adopt it, and bring it in and talk about what has to change along the way. 

I think you can’t just keep doing the same thing again. Both for your company’s survival and thriving, and for your happiness, contentment, and reducing stress. Embrace it in that way.

You may also like…

Report: Software engineers increasingly seen as strategic business partners

The real problems IT still needs to tackle for platforms

The post Q&A: Why over half of developers are experiencing burnout appeared first on SD Times.

Fluid Framework 2 includes four major updates, the first of which is a new SharedTree Distributed Data Structure (DDS) that provides a programming interface for working with data. It supports many different data types, such as primitives, objects, arrays, and maps. It also includes features like the ability to listen for changes and track revertible objects on undo/redo stacks, the ability to group changes, an easier way to create granular event listeners, and support for recursive types in schemas. 

Next, it adds a new relay and storage solution for SharePoint Embedded that allows users to keep collaborative data within Microsoft 365 tenants. According to Microsoft, this allows developers to benefit from the security and compliance benefits of Microsoft 365 storage.  

Fluid Framework 2 also introduces Fluid DevTools, which is a browser extension for writing and debugging Fluid apps. Key features include container state and data visualization, the ability to modify container state for testing offline, framework event logs, telemetry graphs, and visibility into audience membership, permissions, and join/leave logs. 

And finally, this version also includes a package that provides telemetry data that can be funneled into any analytics tool. This allows application developers to monitor application usage and look for issues or areas that could be optimized. 

Additionally, Microsoft announced that several of its new experiences are powered by Fluid Framework 2 as well, including:

• Microsoft Loop, a collaborative workspace similar to Notion
• Edge Workspaces, which allows Edge users to organize browsing tasks into dedicated windows 
• Teams Live Share, which is an SDK that can be used to create collaborative experiences within Teams

You may also like…

Anthropic updates Claude with new features to improve collaboration

Microsoft hit with antitrust violation warning in EU over bundling of Teams

Q&A: How cognitive fatigue impacts developer productivity

The post Microsoft’s Fluid Framework 2 is now production ready appeared first on SD Times.

This news comes near the one year anniversary of the Canva Developer Platform, which allows developers to build apps for Canva. 

The Connect API portfolio consists of several different APIs:

• Autofill API allows developers to connect data sources to Canva
• Designs API provides access to existing Canva designs
• Assets API allows files to be synced to Canva
• Folders API enables developers to create, edit, update, delete, or manage a Canva user’s folders
• Exports API provides a way to publish designs in multiple formats
• Comments API allows users to receive and reply to Canva comments from anywhere 

With these new APIs, developers will be able to integrate Canva into different platforms, like  marketing automation software, digital asset management, or file management platforms. 

In addition to making Connect APIs available, the company also reveals updates for its existing Apps SDK. Apps SDK now has new APIs for image, video, and text editing. 

“With support for these new capabilities, developers can enjoy access to an extended range of resources that empower them to bring their best app ideas to life – and put them into the hands of the 185 million people using Canva each month. They can build securely in Canva while making a genuine impact on our community’s design experience and workflows with apps that supercharge our Visual Suite’s current functionality,” Canva wrote in a blog post. 

And to better support developers, the company also introduced a new Partner Program, which provides access to a design team that provides detailed guidance, app templates, and app analytics. 

You may also like…

• Q&A: How cognitive fatigue impacts developer productivity
• Report: Software engineers increasingly seen as strategic business partners

The post Canva expands Developers Platform with launch of Connect APIs appeared first on SD Times.

While most workers work 40 hour work weeks, experts say that most workers cannot do eight straight hours of deeply focused work everyday as they’d mentally exhaust themselves before getting to that point. 

Recently on SD Times’ podcast, What the Dev?, we interviewed Hans Dockter, CEO of Gradle, about the impact of cognitive fatigue on software productivity. Here’s an abridged version of that conversation: 

David Rubinstein, editor-in-chief of SD Times: To start us off, what exactly is meant by the term cognitive fatigue?

Hans Dockter:  What cognitive science has discovered is that there are two types of cognitive work. So the first is learned, effortless routines where you have an input and an output, and there is established programming in place of how to get from the input to the output. You’re walking through a forest and you’re not running into trees, but there’s no learning happening, right? Another example is professional chess players opening the game. You can wake them up at 3am in the morning and they will not make a mistake with the opening. 

And then there is a second type of cognitive work, which is tasks that require so called cognitive control. So you have an input, you have a goal, and you don’t know how to get to that goal. Going back to the professional chess player, at one point, the space of possibilities grows exponentially, that’s the beauty of the game. So it’s no longer an effortless routine, now you have to really work hard to win that game, and that’s where you win or lose the game most of the time. And when it comes to writing software, you need cognitive control.

The interesting thing is that the learned effortless routine is not leading to cognitive fatigue. You can do openings probably all day, you can walk through the forest all day and you’re not like, oh, I can no longer figure out how not to hit the trees; your muscles get fatigued, not your brain. But activities that require cognitive control, they lead to cognitive fatigue. And I think this is really really noteworthy. 

I think we are with software development where we might have been with sports 50 years ago, i.e. no pain, no gain, the more it hurts the better, right? Look at Lebron James and his afternoon nap. This is not because he’s lazy, it’s because he wants to be at peak performance. And I think we’re still in an archaic way of looking at brain work when it comes to software, but it’s the same thing, right? You need to understand your body to be the best athlete you can be, and all the sports science has evolved so much and it has completely changed the game. That’s why LeBron is still one of the best players in the world at age 39.

DR: Interestingly, so you know, we work in industries where a lot of thought has to go into what you’re doing. When I’m crafting a story, I’m doing interviews, coming up with questions, thinking about things and learning, and at the end of the day, I’m exhausted. And my wife is like, what do you mean, you just sat around all day looking at your computer, how can you be tired? It’s that cognitive fatigue! And you just want to zone out for like an hour and try to recover.

HD: The fascinating thing is we have that experience, we have terms for that. “I’m fried,” “I’m mentally exhausted.” And it’s interesting because at the moment, we only have hypotheses for the biological explanation for cognitive fatigue. So they did some new research that showed there are certain chemicals that are accumulating, i.e. glutamate, and when this has reached a certain concentration, your brain just doesn’t work well anymore. 

DR: How do we solve the problem of cognitive fatigue for developers?

HD: So first of all, I would say, when is it a problem? And when is it not a problem? So if I work eight hours, and I’m completely cognitively fatigued after eight hours, but that resulted in a lot of great code, then mission accomplished, rinse and repeat the next day. The problem is that a lot of stuff that happens during the work day accelerates cognitive fatigue without leading to more output. That’s the problem, and that’s what we have to solve. 

Some people talk a lot about the flow aspect. Context switching accelerates cognitive fatigue, right? There’s so many experiments in psychology where you continuously have to switch contexts, and it’s exhausting. And if you will do this sequentially, you know, 10 exercises of this type, 10 of the other, you are much more effective than doing one at a time. There’s really a lot of evidence behind that. 

As software developers, there is a lot of unnecessary context switching, and I’ll give you an example. Flaky tests. I think it’s very important to reflect on a fundamental truth about writing software: every line of code is a hypothesis. You cannot mathematically prove that this line is doing what it’s supposed to do. And that’s also not how AI is going to work. Again, AI also makes hypotheses, right? A physicist that that has a theory about nature, what do they do? They have a dialogue with nature via experiments. And the software engineer has a dialogue with the toolchain. Hey, compiler, what do you think? Hey, unit tests, functional tests, security checks, etc. That’s why we write tests, right? Otherwise, the customer has to give feedback, and it would very often be negative.

The feedback might take five minutes, 20 minutes, an hour, many hours, so you have a long feedback cycle. And then you have to start working on something else, or you have to wait for the feedback. Google did some research that developers for feedback cycles that take less than 10 minutes, they wait. Now reflect upon that, right? People could say, oh, lazy guys wait, but this is actually an active strategy to avoid context switching and to optimize productivity. They’re basically saying, it’s not worth paying the context switching, the mental cost of context switching, which requires you to change the neural patterns in your brain when you think about something else. 

So it’s a productivity strategy to say, hey, the trade off is not worth it. So when something takes nine minutes, you wait nine minutes, when something takes four minutes, you only wait four minutes. And if you can get it down to 40 seconds, you only wait 40 seconds. 

If you ask most companies, let’s say Fortune 500 companies, how many feedback cycles are your developers running per day? What is the average time of a feedback cycle? And how often do they fail? And what is the reason for the failure? Those are very simple questions, and I guarantee you, hardly any of those organizations could give you an answer to any of those questions. So they don’t even know the most basic stuff of what’s going on. The way I look at it is where we are with the whole complex developer tool chain is that we are at a point where we were with web applications 20 years ago, before we had application performance management. You had no idea how often the shopping cart is not working, how long the checkout takes, nothing. Nowadays, it would almost be like a crime not knowing that, but that’s where we are basically when it comes to the machinery the software developers are using.

The post Q&A: How cognitive fatigue impacts developer productivity appeared first on SD Times.

According to Jellyfish’s 2024 State of Engineering Management report, 90% of respondents said their engineering teams are informing business strategy. 

Additionally, 94% of leaders said that engineers are helping the company achieve business growth goals and 95% said that engineering helps the company be more efficient.

But all isn’t perfect in the world of engineering. The report also found that burnout is prevalent across companies, including engineering teams. Sixty-five of all survey respondents experienced burnout in the last year.

For teams of less than 50 employees, software engineers reported burnout at a higher rate than managers or executives, but as team sizes grows beyond that, engineers begin to experience burnout less often than executives. 

Challenges that engineers are facing that may be contributing to burnout include feeling like leadership is out-of-touch with their challenges (44%) and lack of potential for advancement (34%). Thirty-two percent of the engineers surveyed said they were considering a career change. However, despite these challenges, 80% did still claim that the work they’re doing is rewarding. 

The report also uncovered a stark disconnect between perceptions between leadership and engineers. Seventy-one percent of executives believe that productivity has decreased in the last year, compared to 40% of engineers. Ninety-two percent of leaders feel like they’re out of the loop on engineering challenges, compared to the above-mentioned 44% for engineers. And 46% of engineers say their team is experiencing burnout, compared to 34% of executives. 

According to Jellyfish, this is a sign that companies need to work on finding the proper metrics to track to ensure everyone is on the same page. 

“Engineering organizations are constantly evolving, and the pace of change will only continue to accelerate. Forward-thinking organizations are using effective management backed by hard metrics to stay ahead of the competition,” Jellyfish wrote in the report. 

For this report, Jellyfish surveyed over 600 engineers and engineering leaders and managers between February and April 2024. 

You may also like…

• What makes engineering teams elite
• Combating burnout in development

The post Report: Software engineers increasingly seen as strategic business partners appeared first on SD Times.