No longer do software engineers simply write code and run some tests. Now, they have to manage API integration for required services, security through the use of software bills of materials, the maintenance of these complex applications, and now learn to use AI and understand the risks associated with all of the above.

According to a study released Monday by Atlassian, of the 2,100 practitioners surveyed, the top five areas of developer role complexity are:

• Understaffing – this forces developers to take on responsibilities of other roles (48% of  respondents)
• Expansion of the developer role – bringing in testing, security, operations and maintenance (47%)
• New technology – developers need training on such things as AI and other new tech (47%)
• Switching context between many tools – tool sprawl is a big issue for organizations (43%)
• Collaboration with other teams – this can be avoided through more effective use of tools (43%)

Development team leaders say they understand the importance of the developer experience (DevEx). In the study, 86% of leaders believe that attracting and retaining the best talent is nearly impossible without a great developer experience.

Unfortunately, less than half of the developers surveyed believe their organizations prioritize developer experience.

Most organizations today realize that developer experience and productivity are closely related. Andrew Boyagi, head of DevOps evangelism at Atlassian, believes there are three key factors to creating a positive experience: being able to maintain a flow state, reduced cognitive load, and a constant feedback loop. “When developers have access to the information they need in a centralized format and can review progress in regular data-informed retrospectives, they are able to get more work done and have a more enjoyable experience doing it,” Boyagi said. 

Among the tactics he said Atlassian has seen success with to achieve that ‘developer hat trick’ are providing powerful DevOps tools, empowering teams to take more control over their roadmaps, and creating an engineering culture “that encourages experimentation and knowledge sharing. But the first and most important step is to speak with your developers. You can’t begin to improve friction points if you don’t fully understand where those friction points are,” he explained.

One technique organizations are using to reduce friction points is through internal developer portals (IDP) and platform engineering. The goal of platform engineering is to standardize tooling, but it comes with both benefits and pitfalls. The obvious benefits, according to Boyagi, are reduced software tool costs and reduced developer complexity created by tool sprawl. Among the downsides are sacrificing best-of-breed tooling that developers have come to rely on, or removing functionality that’s required by specific teams within an organization.

“Creating a positive DevEx is a balancing act,” Boyagi said. “In large organizations, a good approach is to standardize on certain areas of tooling, and allow flexibility in others. For example, it’s logical to standardize on a source code repository, so all code is in one place. You may, however, allow teams to choose from a variety of testing tools. Regardless of strategy, for a positive DevEx it’s important that tools are integrated in a way that minimizes context switching, developers outside the platform team have a voice in the selection of tools, and there is a feedback mechanism for the ongoing performance of tooling.”

Developers as generalists

Ethan Sumner, founder and CEO at research and analysis startup DevEx Connect, said the adoption of DevOps practices has turned software developers into generalists, doing a little bit of a lot of different roles. 

“Very early on in my career, I worked for an extremely small company, there were four of us,” he said. “We were all developers, there was no operations. It was just developers, and the operations side was absolutely atrocious. When we did a deployment, it took two days for us to do it, not two minutes, like all these large enterprises have got operations down to a tee. 

“And all of our developer environments were built using Oracle VirtualBox, which took three hours to spin up,” Sumner continued. “And it was a productivity nightmare. But afterwards, I went down to MasterCard, where we did operationally things extremely well. Having these kinds of build environments, development environments, a lot of developers just want to develop and code all day; they don’t want to worry about which kind of staging environment, how does it look going into production, a lot of them don’t want to be on call. I think a lot of organizations are trying to put code developers as true generalists, when really, there should still be a bit of segregation between these kinds of roles. You know, people develop, people operate.” 

Measuring productivity

Before software became so complex, developer productivity was basically measured in the number of lines of code written per day, or hours working. Today, that fails to take into account the wait times associated with the silos organizations have created to separate out work, as well as other inefficiencies, such as waiting on pull requests or even using time to learn more about testing and security.

According to the survey, 41% of organizations use tools that measure developer productivity to assess development team satisfaction. This, the survey said, raises a red flag about whether or not an organization is tracking the proper metrics with the correct tools. 

“Our survey found that more than half of the engineering leaders using [these kinds of] metrics … find them ineffective as a measure of developer productivity,” Boyagi said. “While you can measure productivity, there is no one metric, or set of metrics that rules them all. This is because developer experience and productivity are highly contextual between teams and organizations. Organizations need to look at things from a 360-degree view and focus on three things: developer sentiment (how they feel about their work and environment), workflows (how efficient and reliable systems and processes are), and KPIs (the measures your team obsesses over, based on your specific situation).”

Will AI be a game-changer?

A study by IDC predicts that $40 billion will be spent on AI tools this year. And Atlassian’s study found that development leaders believe that using AI is the most effective way of improving both productivity and satisfaction.

Yet only 30% of responding developers said AI-based development tools will improve personal productivity, and 32% responded “only slightly.” This continues to show the disconnect between how leaders view productivity and satisfaction, and how developers see it.

“AI can help improve developer experience, but it can’t solve all the pain points of development teams to improve productivity and satisfaction,” Boyagi noted. “There is the potential for significant gains in things like incident response, info searching, and documentation but only if applied as a solution to an actual issue developers in an organization are facing. It’s critical for leaders to ask developers about their friction points and then focus on implementing the right solutions and cultural changes to make a difference.”

You may also like…

IDPs may be how we solve the development complexity problem

Q&A: Why over half of developers are experiencing burnout

The post Developers, leaders disconnect on productivity, satisfaction 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.

The DPH Framework describes “the systems, processes, metrics, and feedback systems we use to understand our developers and their needs internally at LinkedIn,” Max Kanat-Alexander, principal staff software engineer at LinkedIn, and Grant Jenks, senior staff software engineer at LinkedIn, wrote in a blog post.  

The Framework can be adapted by organizations looking to implement systems to improve productivity and developer satisfaction. 

It describes the metrics LinkedIn follows, how it chose what to measure, and provides insights into why some metrics are better than others. For example, some of the metrics in place at LinkedIn include Developer Build Time, which is the time developers wait for their builds to finish; Net User Satisfaction, which measures how happy developers are with the internal tools they are using; and Code Reviewer Response Time, which measures how long it takes to a review to respond to code updates.  

The DPH Framework also recommends creating Developer Personas to better understand developers by categorizing them into groups based on their workflows. This enables leaders to think about the priorities separately for each group. 

There are also guidelines for teams who are creating feedback systems, and guidelines for quantitative metrics. 

Finally, the Framework ends with a set of example metrics that companies can base theirs on. 

“Now more than ever, developers are navigating so much change and new opportunity in this new era of Generative AI, so ensuring teams have the systems, processes, metrics and feedback systems to be successful is paramount. Our goal with this release was to offer an answer to one of the main questions we hear asked across the software industry, “How can I help my software development teams be more efficient, more effective, and happier?” We found that the best way to answer this question is through data, usually meaning metrics and feedback systems,” Kanat-Alexander and Jenks wrote.

The post SD Times Open-Source Project of the Week: Developer Productivity and Happiness Framework appeared first on SD Times.

Using the 2,650 responses to its survey, it was able to narrow down seven recommendations to build a high performing team.

• Define a clear purpose and vision

Teams must have clear goals in order to ensure that team members can see how their own skillsets and tasks are contributing to the big picture. 

Dale Carnegie recommends that leaders break big picture goals down into smaller milestones to enable teams to track progress, have discussions, and make changes to improve performance. 

• Close perception gaps between productivity, satisfactions, and culture between leaders and employees 

The study cites a report from Microsoft, which claims that 87% of employees feel productive at work, while only 12% of CEOs believe this is true. 

In order to close this perception gap, the recommendation is to improve understanding on how individual employees experience the workplace. “This gap can be an issue as leaders, reflecting a more favorable view in many areas impactful to team outcomes, can overlook valuable opportunities for improvement and neglect the true needs of the team,” the report states.

• Understand what makes a team satisfied

According to the report, there are often similarities between satisfaction and high performance. Eighty-nine percent of high-performing teams are “very or extremely satisfied” with their team, while only 65% of non-high performers felt the same. 

The top drivers for team satisfaction included the ability to collaborate, group participation, and trust. The qualities that most separated higher and low performers include growth opportunities, cooperation, and the ability to share ideas.

• Facilitate effective team communication

This goes hand-in-hand with establishing a clear purpose and vision, as those ideas need to be effectively communicated across the organization. 

“A collective understanding through effective communication can help a team determine fit within the purpose and vision and provide extra motivation when heavy workloads or high-stress levels exist, ultimately supporting resiliency,” the report says. 

• Have adaptability

This enables teams to adapt to ongoing changes in the workplace. According to the report, 74% of teams that exceed their goals had good access to training and development materials. 

“A commitment to ongoing development opportunities must be a part of the organizational culture. Empowerment is key. Team members need to feel they have the necessary skill sets and permission to act and contribute in a productive way for their work product and colleagues,” the report says.

• Facilitate collaboration and cross-functionality

Dale Carnegie believes that successful teams have coworkers who share a healthy attitude towards each other and understand each other’s roles. 

The research reveals that as the frequency of interaction among teams goes down, so does its chance of being a high-performing team. Collaboration and cross-functionality will remain even more important as new flexible work models, such as fractional work, role sharing, and matrixed teams, take hold. 

• Technology can’t replace culture

As tools like generative AI, natural language processing, and VR/AR are entering the workplace, it’s important for teams to remember that “technology has a supportive role in creating and empowering high-performing teams, not a primary one.”

Dale Carnegie recommends that when exploring these new technologies and how they fit in the team, teams should also consider opportunities for improving their culture as well.

The post Report: 7 qualities of highly effective teams appeared first on SD Times.

The Uno Platform is a platform for building multi-platform .NET apps from a single codebase. 

In the 5.0 release, support for C# Markup has been added. According to the project maintainers, C# Markup was desired by programmers because it allows them to build a full application from just that language. “A massive bit of feedback from the community has been the need to learn multiple languages to build an Uno Platform application,” the Uno Platform Team explained in a blog post. 

C# Markup supports standard WinUI, Uno.Toolkit, and Uno.Extensions controls, or developers can use the C# Markup support generator to use any third-party control. It also comes packaged with capabilities like data binding, styles, resources, templates, and visual states. 

Another benefit is that the language allows app UIs to be created declaratively and have a clear separation between the UI and the underlying business logic. 

The Uno Platform Team also released a Figma to C# Markup plugin, which is inspired by the Figma-to-XAML plugin. 

Several updates were made to the MVUX extension, which implements the Model-View-Update design pattern. It now takes better advantage of Hot Reload, which is a capability that allows developers to update code and run it without needing to pause and rebuild the app. Now, Model and View can be altered without the applications needing to be restarted. 

The team also created a course for learning about Hot Reload. The hands-on workshop guides developers through building a simple calculator that takes advantage of this feature. It also created another workshop that teaches how to build an app for streaming YouTube videos that can be deployed across multiple platforms, which also highlights the benefits of MVUX. 

Other improvements in Uno Platform 5.0 include MP4 camera capture for iOS, improved composition support for Skia targets, improved DPI scaling and theming support for GTK, and more.

The post Uno Platform 5.0 promises “5X productivity” improvement appeared first on SD Times.

Now what?

Dylan Etkin has been an engineering manager for a good portion of his career, and now is a co-founder of Sleuth.io, a company focused on helping organizations continuously improve their software delivery through the use of metrics. He has seen it all, and lists five common mistakes these newly minted engineering managers make.

1. Don’t compare how you would work as an engineer to the team you’re supposed to be managing.

“There’s a change in how you understand value for yourself,” Etkin explained. “Let’s assume some sort of world where you’re a great IC, and you’re used to slinging code throughout the day, and let’s say you’re really, really good, and maybe you’re producing at a five … Now you become an engineering manager, maybe you’re managing a team of five ICs, and they’re all producing at a three, so you start to think about things in terms of 15. But you’re also not tangibly doing that; you’re not showing up each day and getting that satisfaction of personally having driven a five across the line. And that’s a huge mental shift.”

He went on to say that if you’re not taking satisfaction from that new part of the job, you might as a manager feel like you’re not doing something that’s important. “I’ve seen folks … that don’t take management super seriously. They don’t realize that if they adjust their thinking, like getting everybody who’s doing a three to do a four, and that’s suddenly a huge amount of more capacity,” he explained. “Instead, maybe they go off and hide in their IC habits, and the things that give them comfort. If you’ve been an engineer your whole life, and now you’re a manager, your fallback in your comfort zone is going to be engineering.”

2. Understand who you’re reporting to

A second mistake new managers make is not understanding who you’re reporting to and how they want to receive information. Etkin said an engineering manager is part salesman, in that you’re selling the work that your team is doing. But in the absence of the necessary information a new manager might not be delivering up to his managers, those higher-ups will naturally assume the worst, he said. “When I started doing the job, I was like, ‘Hey, my team is doing great. I’m focused down and across. And, everybody knows that I’m so good at things, so they will just assume that this team is going great.’ Yet lo and behold I hear through the sideways mechanism that people are very concerned about how this project is going. And I had to learn the visceral way that I need to be telling people what’s working and what’s not working, and what we’re trying and what we’re focused on and what the impact of that is. And that’s a very different mentality from when you’re an IC.”

That issue starts to get into the topic of value streams, which enables first-line managers to surface the real work in such a way that it can be zoomed out for the next higher levels of management to assess if the project is on time and if the correct amount of resources are being spent on the things the organization is trying to accomplish.

3. Understand the big picture

Another aspect of the role of the manager is to understand the bigger picture and learn the why behind what the organization is trying to do, and then enforce those things.”It’s not always easy. And sometimes, the worst part is when it’s just a terrible idea and you have to enforce it anyway,” Etkin said. Often, the manager will fight over the direction, and if the fight is lost, the manager has to go back to the line engineers to explain the decision. Etkin added, “If you’re a good manager, who’s always communicating to your team and letting them know what the thinking is behind a lot of these things, it makes it easier to deliver the bad news. As long as there’s transparency and communication, it makes it go down easier.” 

4. Understanding your team

Etkin advises to be adaptable to the team that you’re working with. Different people have different styles. “I have had engineering managers that work for me that are extremely pedantic,” Etkin said. “They have a super-manicured JIRA board, and their planning meetings are a walk through issue after issue after thing. And they have been extremely successful.” On the other side of the coin, Etkin said he’s had managers working for him that have very short planning meetings, who simply want to know what the team is doing that week. And once they are sure the engineers know exactly what they’ll be doing to get from here to there, that’s the extent of the meeting. “I think those are great examples of understanding the teams that are working for them,” he said. “So some individuals can work in that mechanism and prefer to do so, while some individuals can’t, and they require a little bit more structure.” 

5. Understanding yourself

And then there’s a balance of understanding what you need yourself, Etkin pointed out. “How much structure do you need, versus how much loosey-goosey units do you need, and then marrying that at the right level, between you and the people that are working for you, such that you can come up with a process that allows everybody to do their best work.”

But he said managers also have to take that a level up to their bosses, who will be on the spectrum of extremely right to extremely open and understanding, to see where the manager is in relation to that individual. “You have to adopt enough things to make sure that that person is satisfied with the way that your team is working too.”

To learn more about making development teams more productive, join us at the upcoming Improve: Productivity one-day virtual conference on Nov. 15. Registration is now open.

The post Common mistakes made by engineering managers that hurt productivity appeared first on SD Times.

“Enterprise survival relies on an organization’s ability to quickly adapt and pivot to market shifts and customer needs, yet a staggering 85% of executives say their company’s ability to adapt to change falls short,” said Razat Gaurav, CEO at Planview. “Planview Roadmaps acts as the connective tissue between strategy and work, connecting every team with unprecedented visualization across the business. This enables executives to detect and respond to changes swiftly, ensuring that strategic pivots cascade seamlessly to the team level, eliminating uncertainty around executing strategic initiatives. The future of connected work is here, empowering organizations to thrive in this fast-paced environment.”

Planview Roadmaps offers a connected and dynamic view of work, allowing organizations to adapt to change by providing visibility into work progress and dependencies. This enables swift responses to changes and delays. Leaders and teams can plan and adjust more efficiently by mapping initiatives to outcomes across all teams, ensuring organizational alignment even in the face of changes, according to the company. 

Planview Roadmaps accommodate various organizational operating styles, such as traditional and Agile teams. They facilitate shared knowledge of interconnected efforts and their outcomes, enabling leaders and teams to manage dependencies effectively. This helps reduce delays, with built-in collaboration features fostering closer teamwork across different methodologies, the company noted.

According to Planview, with Planview Roadmaps, teams can connect strategy with outcomes and team milestones, mapping work to critical outcomes and ensure progress on most critical initiatives. Additionally, because plans, strategy, and outcomes are all visible in one view, organizations can confidently articulate the impact of initiatives and how programs are progressing to drive business change.

The post New Planview Roadmaps combines strategy, team plans, and execution into single view appeared first on SD Times.

With developers getting lost in today’s decentralized, complex world of APIs, libraries, UI elements, frameworks and tools, Compass is designed to guide developers to their true north – delivering exciting new products that align with business goals and satisfy customers.

According to Taylor Pechacek, Atlassian’s head of product for Compass, developers need to navigate through this ocean of complexity to find the information and context they need around the work they’re doing, and to collaborate across the tech stack to make sure the software is kept in a healthy state.

So this, he said, is not just a technology problem, but very much a collaboration problem.

Pechacek explained that Compass improves the developer experience by creating a single, reliable and standardized place to capture all the context around the code. “There’s all these different software components out there, so an individual service is not just its code anymore. It has dashboards and observability. It has security issues coming in against it, it has compliance that the organization needs to stay on top of.” 

What they’re going to be able to do with Compass, he explained, is that they’re going to be able to empower developers to work autonomously. “They’re going to be able to increase overall engineering velocity by spotting those outliers. They’re going to be able to improve reliability, because developers and those teams understand how those pieces fit together.”

Pechacek noted there are four key default features in the Compass release. The first is a unified software component catalog to help users track all their services and relevant data and untangle their technical architecture all in one place. “Where is that run book?” Pechacek cited. “Which Slack channel do I actually contact? What is the latest deployment of this? Developers are going to be able to reduce time spent searching for this information, and they’re going to be able to get back into that flow state faster.” 

The catalog is being made available for free to Atlassian customers.

The second are health scorecards that help organizations track delivery and team health metrics to “identify points of friction for development teams and improve reliability for existing services,” Atlassian announced.

As Pechacek explained, “Once you have a consistent model of those components there, you can establish and evaluate the health of the company’s architecture and the team health. How do I keep all of my critical services secure?” The scorecards, he said, make it easy to monitor that progress. And if there are any regressions in the architecture health, such as having too many open security vulnerabilities, or incidents are eating up too much of your sprint, he added that “you can accelerate those feedback loops so that developers are not being interrupted by these apps coming across the business, and they’re able to get back to fulfilling more complex challenges for their team.” 

The third foundational component of Compass is templates. Pechacek explained that whether they’re creating a new service or a new library, developers often have to go through hours of configuration and library setup just to be able to write a piece of code. With the templates included in Compass, the organization can bake in best practices and enforce consistency. “So when a developer says, ‘Yeah, I need a new back end service to build my feature,’ that’s a one-click experience for them,” he said. “Essentially, they get all the infrastructure, they get their pipeline, they get the libraries that the company wants to give them, all the configuration settings and so forth. This is the happy path… and will help developers get started very quickly.”

The final piece is around extensibility, with Compass “being able to bring together information scattered across the organizations’ toolchain and ties it to relevant services and teams,” Atlassian wrote in its announcement blog. 

Compass allows development organizations to integrate across their existing tool chain, and to interact with that data. Pechacek notes that Atlassian’s APIs are free and accessible, and developers can collaborate with access to that information, coming from code, coming from CI/CD and observability, and take that information from Compass and put that back into other tools. “So now, my scorecards are part of my Jira Software sprint, to know how to prioritize technical debt versus innovation and new features,” he said.

Want to learn more about making developers more productive? Join us at Improve: Productivity, a one-day virtual event on Nov. 15. Learn more here.

The post Atlassian announces release of Compass DevX Platform appeared first on SD Times.

The global movement towards distributed work has fueled a need for new ways to help teams collaborate when they are not in the same location or even the same hemisphere. Asynchronous (async) video has been at the forefront of this movement with Loom’s business users recording almost 5 million videos per month.

“Async video is the next evolution of team collaboration, and teaming up with Loom helps distributed teams communicate in deeply human ways,” said Mike Cannon-Brookes, co-founder and co-CEO of Atlassian.

Atlassian has deep expertise in how teams work. It’s already the go-to place for over 260,000 customers who plan, track and get work done, and the addition of Loom will further elevate the collaboration experience for teams. Soon, engineers will be able to visually log issues in Jira; leaders can use videos to connect with employees at scale; sales teams can send tailored video updates to clients and HR teams can onboard new employees with personalized welcome videos.

Furthermore, by integrating Atlassian’s and Loom’s investments in AI, customers will be able to seamlessly transition between video, video transcripts, summaries, documents, and the workflows developed from them, providing multiple ways for teams to connect and collaborate.

For Loom customers, the acquisition will bring the benefit of Atlassian’s platform and portfolio of products, allowing users to plug async video directly into key workflows in Jira and systems of record in Confluence.

“Loom’s vision is to empower everyone at work to communicate more effectively wherever they are, and by joining Atlassian, we can accelerate their mission to unleash the potential of every team,” said Joe Thomas, co-founder and CEO of Loom. ”We’re excited to weave video into collaboration in a way that only Loom + Atlassian can.”

Details Regarding the Transaction

Under the terms of the definitive agreement, Atlassian will acquire Loom for approximately $975 million, inclusive of Loom’s cash balance, subject to customary adjustments. Total consideration will be comprised of approximately $880 million in cash, and the remainder in Atlassian equity awards, subject to continued vesting provisions.

Atlassian expects to fund the cash consideration through existing cash balances and the transaction is not expected to have an impact on the company’s share repurchase strategy.

The transaction is expected to close in the third quarter of Atlassian’s fiscal year 2024, subject to customary closing conditions and required regulatory approval.

The acquisition is expected to be slightly dilutive to non-GAAP operating margins in fiscal years 2024 and 2025.

Loom Background

Founded in 2016, Loom is a video messaging platform that helps users communicate through instantly shareable videos. Known for their ease of use, users simultaneously record their desktop screen, camera, and microphone creating rich documentation of institutional knowledge. With transcripts in 50+ languages and AI features that write titles, summaries, chapters, and tasks, Loom videos become important company know-how to be shared, reused, and self-served across teams.

Sharing many similarities with Atlassian’s mission, product-led go-to-market motion, and culture, today Loom serves over 200,000 customers.

For further details on the announcement from Mike Cannon-Brookes, head to Atlassian’s Work Life blog.

About Atlassian

Atlassian unleashes the potential of every team. Our agile & DevOps, IT service management and work management software helps teams organize, discuss, and complete shared work. The majority of the Fortune 500 and over 260,000 companies of all sizes worldwide – including NASA, Kiva, Deutsche Bank, and Salesforce – rely on our solutions to help their teams work better together and deliver quality results on time. Learn more about our products, including Jira Software, Confluence, Jira Service Management, Trello, Bitbucket, and Jira Align at https://atlassian.com.

The post Atlassian acquires Loom appeared first on SD Times.

Some believe that lines of code written per day is still a valid metric. Some say you should measure development teams, not individuals.  Others say productivity stems from removing obstacles in the SDLC toolchain, and still others find more esoteric explanations.

Andrew Boyagi, senior technical evangelist at Atlassian, believes developers are most productive when they are happy. “Developer joy is the key to developer productivity,” he said. But unfortunately, the goals of companies often don’t align with work that gives developers joy, and since developers are paid to do a certain job, they often have to do things they find more mundane to put food on their tables.

Yet Boyagi believes the goals of business and developers are actually aligned, “but they speak past each other,” he said. “Senior leaders want their developers to be productive. If you look at a CIO or CEO, their primary concern probably isn’t developer joy. It’s more about getting products quicker into the market, satisfying customers, increasing revenue, doing more with less.” But to get that, he said, developers need to be happy to be productive. If leaders aimed for developer joy, they would get the outcome that they are after.

The software industry is perhaps unique in that developers already start with an inherent level of joy. They have a love of the craft and they love to share their knowledge with videos, tutorials and participating in online forums to talk about software development. Companies should foster that joy instead of taking it away. Boyagi believes it comes down to two things – the developer experience and engineering culture. 

“The developer experience is, how do they feel about the tools they use, the frameworks, everything that goes around that part of their role,” he explained. “And then you’ve got culture, which is, what are the values of the company? How do decisions get made? What are the legendary stories that get told around the company about this awesome thing they built, or something that happened in the company. Those two things together are really what drives developer joy, or allows it to flourish in an organization.”

There’s been a discussion forever about software development being an art or a science, and Boyagi thinks about it as an art, because there are so many different ways to get to a desired outcome. If you ask three artists to paint a fruit bowl, they will, but their paintings will likely be different from one another. “It’s the same with software development,” he said. “And so, you think, how do you measure the productivity of an artist? Do you count the brushstrokes? No, you don’t.”

What you should do, he continued, is give developers what they need in terms of tools, and  put them in an environment where they’re going to be happy and do their best work. “You give them the context and the brief of what you’re after, and then you let them do their magic.”

Boyagi does believe that some measure of work is important, especially for the CIOs and CTOs. “It feels nice and comfortable to measure it, because it’s a complex thing. Measures or metrics help simplify and justify, ‘Hey, look at how well we’re doing.’ Maybe spend some time doing that. But if you have 5,000 developers, spend three days speaking to them, and you’ll get 20 things you can do to improve their productivity. And I think that’s a much more valuable way to go than spending all your time trying to measure it.”

Andrew Boyagi will be presenting “Weaponized Developer Productivity – How Good Intentions Lead to Bad Outcomes” at the upcoming Improve: Productivity one-day virtual conference on Nov. 15. Registration is now open.

The post To help developers be more productive, foster joy appeared first on SD Times.