devopsy.kinsta.cloud

Tag: developer productivity

  • Tips for Increasing Developer Velocity in the AI Age

    Tips for Increasing Developer Velocity in the AI Age

    These days, everyone is trying to improve release frequencies. Under mounting pressure to deliver more, many software teams are considering new strategies to enhance their developer velocity, like AI-assisted code development and platform engineering. AI has been a boon for automatic code generation, but all the code in the world doesn’t matter if you can’t deploy it into production efficiently.

    Another point is that velocity isn’t always measured productively, said Dori Exterman, chief evangelist of Incredibuild and a self-proclaimed ‘productivity freak.’ Too often, managers place value on quantitative elements, such as points per sprint and unrealistic metrics, when they really should be considering the quality of these components and how easy they are to maintain in the long run.

    I recently chatted with Exterman and other experts about tactics organizations can use to enhance their development velocity. Below, we’ll consider some helpful methods, from optimizing testing automation to creating internal development platforms (IDPs) and evolving your CI/CD processes. Essentially, optimizing the plumbing will be necessary to match the productivity of instant code generation—otherwise, the vision of continual release will remain stunted.

    New AI, Same Plumbing…

    No tech article today can mention developer productivity enhancements without a nod to AI. Just take the interest in Copilot, for example. Among GitHub Copilot users, 40% of the code they’re checking in is now AI-generated and unmodified, according to a Microsoft executive. And GitHub reported that 88% of Copilot users feel more productive when using the tool.

    In contrast to past hype cycles, the latest AI wave is not just a passing fad—it will have long-lasting effects, said Exterman. However, most of our current DevOps processes were constructed for manual code writing, not for the era of AI-assisted development.

    If you quadruple the amount of water you use but use the same plumbing system, you can’t push more water through, said Exterman. Similarly, if you amplify the amount of code you’re producing but don’t evolve your build processes, staging and testing, then DevOps suddenly becomes the new blocker.

    Ways to Accelerate Developer Velocity

    So, how can we improve development efficiency and productivity in the age of AI? Here are some actionable strategies for overcoming these bottlenecks and improving developer velocity.

    Accelerating the Plumbing

    Exterman stresses the importance of leveraging AI to enhance the foundational processes of development. This involves using techniques such as distributed computing and smart test selection to streamline build and testing processes. By optimizing these foundational steps, development teams can ensure that their coding efforts translate into efficient and rapid progress.

    Optimizing Testing through AI

    AI’s potential not only lies in code generation—it extends to optimizing testing processes. Exterman suggests tools like Launchable that allow AI to prioritize tests that matter most. This strategic approach to testing enables teams to focus on high-impact areas while maintaining comprehensive test coverage.

    Embracing Test Automation

    Exterman underscores the importance of comprehensive test automation. Rapid iteration loops are essential for maintaining velocity, and automation facilitates fast feedback cycles. This approach ensures that each code change undergoes rigorous quality checks, preventing errors from propagating downstream.

    Keeping an Eye on Technical Debt

    One of the potential downsides of increasing programming velocity is the accumulation of more technical debt. As more development occurs, the temptation to compromise on documentation, unit testing and best practices grows. Exterman emphasizes that velocity must be pursued in tandem with managing technical debt to ensure the long-term health of projects.

    Investing in Platform Engineering

    Recently, we’ve witnessed a paradigm shift toward platform engineering. Just over half of IT organizations have already embraced platform engineering, according to the 2023 State of DevOps Report. Exterman emphasizes the need for a robust internal developer platform that supports the seamless transition of code from development to staging and production. For instance, tools like Terraform and Earthly play a pivotal role in establishing testable environments and reproducible builds.

    “Bring more data services closer to the developers,” said Venkat Ramakrishnan, VP, product management and engineering, Portworx by Pure Storage. “Choose platforms that provide easy-to-deploy services that developers can consume and provide visibility and control into the underlying costs.”

    Enabling Observability

    Observability, according to Exterman, is also important for gauging efficiency. The ability to continuously monitor and log processes enhances the overall development cycle. One report from Splunk even found that 64% report their investment into observability has exceeded their expectations. Tools from New Relic and Datadog, for example, offer insights that tie quality, delivery and productivity together, enabling teams to make informed decisions.

    Evolving CI/CD With Continuous Merge

    One method to progressing CI/CD is continuous merge, a new concept that can be implemented with tools like gitStream that aims to decrease the window between a pull request, review and merge.

    “CI/CD has done wonders to improve the quality and efficiency of the software development toolchain, but it mainly focuses on things that happen after code has been written and reviewed,” said Ori Keren, CEO and co-founder of LinearB. “Continuous merge is a mindset that extends CI/CD practices further upstream to improve the quality and efficiency of the code review process. We’ve reached a point where code review times frequently cause the most significant delays in the software delivery process; continuous merge is how we fix that.”

    Using Cloud-Agnostic Platforms

    Cloud-native development has become more popular as organizations seek to design software architectures bred for the natural scalability of the cloud. Simultaneously, both technology and business motivators are resulting in a multi-cloud condition. In this scenario, IT really needs agnostic, open platforms to retain flexibility and reduce bottlenecks.

    “Enable developers to build their apps in a cloud-agnostic way so they can scale their apps globally,” said Ramakrishnan. “Much of developer and app momentum is lost when scaling apps. Helping the application teams architect it right by providing cloud-agnostic application platforms like Kubernetes enables developers to move faster, scale faster and reach their customers everywhere.”

    Measuring Developer Velocity

    The above tips should help improve velocity, but how exactly should you measure success? Well, measuring developer velocity goes beyond simply tracking the number of points completed in a sprint, reiterated Exterman. He emphasizes the importance of focusing on the ability to deliver high-quality products to the market swiftly. He underscores the need for a fast feedback loop for addressing bugs and iterating quickly. AI plays a role here, too, aiding in test writing and enabling continuous delivery.

    End Benefits of Improved Developer Velocity

    Exterman concludes by highlighting the real-world benefits of increased developer velocity. Faster bug-fixing and release cycles, particularly crucial in industries like gaming, result in improved user experiences and customer satisfaction. He emphasized the significance of aligning key performance indicators (KPIs) and objectives and key results (OKRs) with the aspects that truly matter, promoting a culture of measured and sustainable progress.

  • Is ChatGPT Helping or Hurting Your Developers’ Productivity?

    Is ChatGPT Helping or Hurting Your Developers’ Productivity?

    ChatGPT’s ability to translate natural language into working code has sparked tremendous interest in the programming community. Developers are exploring ways to use ChatGPT to reduce redundant tasks, from creating code snippets to analyzing and debugging programs. This also allows them to focus on more complex tasks like data analysis and monitoring with the help of a strong full-stack observability platform. Despite ChatGPT’s impressive capabilities, developers and their employers are split on whether the AI chatbot significantly boosts developer productivity.

    We will explore how to use ChatGPT to benefit your developers’ productivity and go over the advantages and disadvantages of ChatGPT to help you make the right decision for your business.

    How to use ChatGPT for Better Productivity

    ChatGPT has quickly become the most popular intelligence chatbot, with over a million user signups in its first five days and over 100 million in the first two months. Here are a few ways ChatGPT, developed by OpenAI, can help boost productivity in your organization.

    Improve Their Code
    Sometimes manually written code snippets consume additional CPU resources. Using ChatGPT, developers can optimize their functions for better performance. Additionally, ChatGPT can also write test cases and spot security vulnerabilities in their code, helping developers work faster.

    Simplify Documentation
    ChatGPT can give a simple explanation for the layman, avoiding technical jargon to a large extent. For instance, a developer at Twitter fed ChatGPT their code and it responded with a pretty detailed explanation. Using ChatGPT to generate the first draft of a company’s internal documentation would make knowledge transfers easier. New hires could quickly get up to speed on the company’s codebase. Further, ChatGPT could also be used for external-facing documents where other developers can learn how to use the company’s APIs and frameworks.

    Test and Understand Code
    ChatGPT can write automated tests for code that is fed into it. Although many developers consider testing boring and stressful—and sometimes a waste of time—it’s a critical step in ensuring that published applications are bug-free.

    With ChatGPT, developers can output reliable, well-tested code much more quickly and easily. ChatGPT can also give high-level and line-by-line explanations of code and even teach developers how to use external modules and APIs in their own code, helping them build much faster.

    Debug Code
    ChatGPT makes a great debugging tool for developers. It can take in error messages and output information on the likely cause of the error and how to fix it. This is typically a lot more time efficient than browsing forums and blogs for a solution.

    The tool can also suggest helpful code alternatives. Many developers claimed that ChatGPT can be much faster and less mentally challenging than the conventional approach of searching the web for a solution.

    As the CEO of Replit, Amjad Masad, put it, “ChatGPT could be a good debugging companion; it not only explains the bug but fixes it and explains the fix.”

    Code Comprehension
    ChatGPT’s terabytes of training data come from various sources, including common crawl and WebText2. This training data makes it easy for ChatGPT to simplify explanations of complex pieces of code for developers. Therefore, developers can save time deciphering any code’s underlying logic and structure.

    For instance, Stanford instructor and well-known developer Matt Harrison used ChatGPT to build a simple graphic design tool. He explained, “I’m using ChatGPT to create a GUI program for drawing lines. I haven’t used QT [a development framework] in years, yet I can throw this together really quickly.”

    Generate Documentation
    Writing code documentation is often considered a mundane task by developers. With ChatGPT, developers can significantly cut down on the amount of time needed for documentation. For instance, they can expedite the creation of troubleshooting guides, tool user manuals and test cases by asking ChatGPT to perform code analysis and generate detailed technical reports. Accelerating this documentation process allows for easier onboarding of new developers and faster product release times.

    Writing Tests
    ChatGPT can analyze code snippets and automate testing for them, saving developers lots of time and helping them output reliable code. Test coverage is an essential metric for most enterprises, and ChatGPT could help streamline the process.

    ChatGPT Disadvantages

    While many developers have praised ChatGPT for increasing developer productivity, others have criticized it as unreliable. Let’s understand some key areas where the tool falls behind.

    Outputting Buggy or Unusable Code
    Developers have complained that the chatbot would sometimes output plausible-looking code that doesn’t work. This might result from misunderstanding the user’s requirements or simply being unable to come up with a correct answer—then faking it.

    Programming Q&A forum Stack Overflow even issued a temporary ban on ChatGPT-generated answers. The ban was because the chatbot generated an influx of answers whose average accuracy was pretty low. ChatGPT sometimes uses nonexistent commands and outdated modules in its code, so while they theoretically might make sense, they don’t work in practice.

    Writing Outdated Code (and Forgetting Previously Written Code)
    Since ChatGPT’s training data cut off in September 2021, the chatbot has no knowledge of the recent developments in programming languages and modules after that. As a result, ChatGPT often needs to use outdated commands, modules and paradigms in its code.

    ChatGPT also occasionally forgets the context within which it is working, affecting code output. Some users have reported that ChatGPT sometimes forgets about the task at hand and begins generating incompatible code.

    Security Concerns
    Security concerns are the biggest drawback to having developers work with ChatGPT. Open AI uses the data users input into ChatGPT to train the underlying AI model.

    Research by cybersecurity firm Cyberhaven has shown that 11% of the data employees input into ChatGPT is confidential. This presents a significant risk, as such data can be used in the chatbot’s next responses. Corporations like JPMorgan and Verizon have even gone as far as to block employees’ access to ChatGPT because of these concerns.

    Lacks Problem-Solving Skills
    A developer’s job is to understand the business problem and develop customized solutions to address it. Although AI/ML tools like ChatGPT help developers code faster, they can’t help in problem-solving or implementing a software application.

    Furthermore, when developers become overly reliant on AI-generated code, they’re discouraged from upskilling on new programming frameworks and languages. This can hurt the organization in ways that might not be evident immediately.

    To ChatGPT or not to ChatGPT

    As Google’s head of developer experience Bret McGowen said, “While AI will transform software development in many ways, human judgment, intuition and creativity will remain essential to building great products.”

    While ChatGPT may not be a perfect solution for every aspect of software development, it can be a useful addition when combined with human problem-solving skills. However, companies should be careful while allowing the usage of AI in day-to-day processes. Guidelines educating in-house developers on the fair usage of AI are a must to protect sensitive information and maintain a high-quality control process.

  • Don’t Let Developer Experience Break Your Business

    Don’t Let Developer Experience Break Your Business

    As organizations digitally transform to support the needs of customers and help them win in their markets, IT leaders, software developers and DevOps teams have emerged as the central players in the transformation landscape. They are also key advocates for improving the developer experience and promoting technology adoption—both critical components of a successful digital transformation. They are also on the front lines of understanding operational and team challenges. Their understanding of the business objectives and the role people and technologies play in support of achieving these goals makes IT an indispensable driver of value creation.

    Digital transformation has also fueled the swift adoption of Kubernetes and cloud-native technologies, which promise enterprise speed and scalability. As these technology adoptions accelerate, so too does the demand to make developer experience a priority. After all, developers are tasked with creating and delivering software to the market quickly to support business objectives.

    As more organizations adopt cloud-native development methodologies, developers have taken on a more strategic role across the business. No longer just writing code, they have been asked to take on ownership of the entire application life cycle. In the cloud-native environment, this shift in developer responsibility comes with an evolving ecosystem of technologies and tools that can have enormous complexity and impact how dev teams collaborate as they code, ship, test and run apps to support business goals.

    Asking developers to take on this level of responsibility is not ideal for productivity. Most developers want to know enough about the full software development life cycle (SDLC) and infrastructure to get their work done but do not want to become Kubernetes experts. Giving developers a good developer experience relies on understanding the importance of creating an experience that removes friction, fosters innovation and fuels the ability to move faster.

    Here are four tips to ensure the developer experience is not your Achilles heel in fueling business performance:

    Share the Why: Don’t just tell developers how to do something. Explain why they’re doing it. Storytelling and making the ‘why’ matter play an often hidden but important role in undoing developer frustration and, hopefully, avoiding it altogether.

    With the pressure to do more with less, ensuring that developers understand the reasons behind their actions and activities is key to relieving their frustrations and getting to safer, faster deliveries that underpin business value. Developers don’t like black boxes, and the more you can share upfront about why and how the plan or strategy works, the better the developer experience.

    The 2022 Stack Overflow Developer Survey found that well over half of the developers polled spent more than 30 minutes a day looking for solutions to problems. Not only is this a distraction from core development work and productivity, but it can also account for up to 650+ hours of lost time per week (in a team of 50 developers). Informing developers about the ‘why’ from the start—and then arming them with the right tools—can alleviate both developer and business challenges.

    Reduce Friction and Preserve Existing Workflows: Developers want to focus on what they do best—writing code. They don’t want to be hunting down answers to problems created by a growing list of complex technologies, processes and tooling that impact their ability to write and ship software fast. Most developers don’t want to think about selecting or having to use a variety of different (or new tools) to support their work.

    Clear the path for developers. Find infrastructure that puts your developers in the driver’s seat and allows them to continue using the toolchains they already know and love and the power to pick and choose which capabilities best support their requirements for fast, scalable app delivery.

    Foster Team Collaboration and Communication: Faster, safer development is not just about developer experience, but includes the experience of the entire development team and its ability to collaborate. The entire DevOps team plays a critical role in getting software out the door. Site reliability engineers (SREs), for example, play a key role in guiding developers through the cloud-native learning curve to use platforms and ecosystems effectively. It’s more than firefighting—it is a trusted partner to create success in deploying, releasing and running services.

    Encourage developers to share pain points and learn about tools and best practices from the SRE team. Rethink communication patterns to unify developer and SRE approaches to problem-solving, i.e., remove the “this is a developer problem” or “this is an SRE problem” to reframe them as “this is a business problem” and shared responsibility.

    Let Developer Voices be Heard: Empathy cushions every good developer experience. This includes listening to and understanding the needs and wants of developers. Offering more training, having a robust onboarding experience, focusing on reducing cognitive load and having an ongoing dialog with developers shows empathy and reinforces your commitment to supporting developer skill sets and roles within the organization.

    Organizations that empathize with their developers can eliminate friction and fuel a more collaborative, supportive onboarding experience that allows developers to provide input as they progress in their journey. Continuing that empathy throughout a developer’s time at an organization fosters an overarching culture of communication, collaboration and empathy.

    Additionally, institute measurable and realistic key performance indicators (KPIs) as this will help organizations quantitatively understand the developer experiences and identify areas for improvement and celebration.

    Many organizations that go cloud native to improve development speed and shipping frequency end up in a situation where they ask themselves, “Why is it taking hours to do what we used to do in minutes?” Here it is essential to return to the core question about developer experience. If developers are struggling with hours of repetitive, non-core work, a clear path is not paved for them. If they never got a solid onboarding, there’s no shared development environment, friction is everywhere and lines of communication are closed, it’s inevitable that the developer experience will suffer—and by extension, so will the business.

    How you respond to the needs of the developer and the developer experience can make or break your business. Invest in the developer experience. It’s critical to fueling developer productivity and supporting a faster time-to-market for your business.

  • 92% of Devs Use AI, Survey Says ¦ Intel One Mono Font

    92% of Devs Use AI, Survey Says ¦ Intel One Mono Font

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: GitHub touts unbelievable AI stats, and Intel’s beautiful open source typeface. (more…)

  • Red Hat Unveils Developer Hub to Boost Dev Productivity

    Red Hat Unveils Developer Hub to Boost Dev Productivity

    At its Red Hat Summit conference today, Red Hat unveiled its Red Hat Developer Hub, a developer portal that provides access to an opinionated set of development tools based on the open source Backstage project.

    The portal pulls together a set of curated tools and resources so that developers encounter less friction and avoid the complexity of numerous optional tools that span disparate vendors. The goal is to increase developer productivity while reducing the volume of optional tools and information that must be sifted through to actually deliver production code.

    Red Hat Developer Hub aims to streamline the development process and allow organizations to maximize existing resources and developer skills while reducing sprawl, said Chris Wright, CTO and SVP for global engineering at Red Hat. This will help organizations maintain application development velocity and drive a consistent user experience for developers based on tools and skills they’re already familiar with, Wright told attendees.

    Rather than building and maintaining their own internal developer portal, Red Hat is making a case for using Developer Hub to deliver a platform approach to addressing the complexity and sprawl DevOps teams face. Red Hat Developer Hub is, in essence, an opinionated and optimized version of Backstage that aims to deliver improved developer experiences across environments, including Kubernetes and container application platforms such as Red Hat OpenShift.

    Developer Hub will offer a single pane of glass to view all available developer tools and resources, developer self-service capabilities and security and compliance guardrails for cloud-native application development that comply with enterprise-wide best practices, according to the company.

    Additionally, Red Hat Developer Hub includes a set of ‘golden path’ templates—pre-defined, pre-architected and supported templates for further accelerating application development.

    The developer hub is based on the Cloud Native Computing Foundation (CNCF) incubating open source project Backstage, originally developed by Spotify and donated to the CNCF in 2020. Backstage is now being advanced by contributions from multiple vendors, including Red Hat.

    Backstage has been gaining traction in cloud-native application environments that are especially challenging to develop using multiple tools. There’s a lot more focus on developer productivity, which Backstage addresses by creating a catalog of blueprints that developers can readily consume rather than requiring them to build these capabilities themselves multiple times over. The goal is to create scaffolds that developers can consistently reuse across multiple application development projects.

    Red Hat has also developed Red Hat Plug-ins for Backstage, a bundle of six plug-ins that integrate various key systems into Backstage, helping to extend the project’s functionality, ensure a consistent user experience and improve workflow efficiency. The plugins can be used across all Backstage installations, providing even more flexibility for developers across platforms and Kubernetes distributions and include:

    • Application Topology for Kubernetes, which enables developers to visualize real-time status of application and infrastructure workloads deployed to any Kubernetes target, including Red Hat OpenShift, with greater consistency.
    • Multi-Cluster View with Open Cluster Manager (OCM), which provides a view into clusters from Open Cluster Manager’s MultiClusterHub and MultiCluster Engine in Backstage.
    • Container Image Registry for Quay, which improves the integration and speed of interactions with Quay registries by providing a view into container image details. This includes security vulnerabilities (CVEs) associated with deployed images.
    • Pipelines with Tekton, which gives users a view into the details of all Tekton pipeline runs and their respective statuses across all services.
    • Authentication and Authorization with Keycloak, which enables platform engineers to load users and groups from Keycloak into Backstage, allowing the use of multiple authentication providers to be applied to Backstage entities.
    • GitOps with Argo CD, which helps track the health and status of the Argo CD status for services within Backstage.

    Red Hat said additional plugins are in the works. Red Hat Developer Hub will be generally available later this year, but Red Hat is offering a ‘test drive’ through the upstream IDP project Janus.

     

  • Spotify Adds More Plugins for Backstage Developer Portal

    Spotify Adds More Plugins for Backstage Developer Portal

    Spotify this week added additional plugins for its open source Backstage platform that is used to build developer portals. The new plugins make it simpler to address role-based access and access Insights, a tool from Spotify that tracks Backstage usage trends.

    In addition, Spotify is also enhancing a Soundcheck plugin for Backstage that is used to visualize and track development of software components. Forthcoming capabilities include a no-code interface that makes it possible to programmatically create checks of code without writing any code.

    DevOps teams will also be able to view, export and understand how teams and components are doing compared to established best practices and monitor trends, graphs and historical views, and receive notifications when levels change.

    Finally, Spotify is committing to adding additional integrations with third-party tools and platforms such as Snyk, Sonarqube and the open source Argo continuous delivery (CD) platform.

    There are now five plugins available via a Spotify Plugins for Backstage subscription service, and Spotify said more are planned.

    Meg Watson, a group product manager at Spotify, said Backstage has been gaining traction in cloud-native application environments that are especially challenging to develop using multiple tools. Because of Backstage, developers are not only more productive but turnover has also been reduced because developers are provided with a better experience, she noted.

    There’s a lot more focus than ever on developer productivity, which Backstage addresses by creating a catalog of blueprints that developers can readily consume rather than requiring them to build these capabilities themselves multiple times over. The goal is to create scaffolds that developers can consistently reuse across multiple application development projects.

    Backstage was donated to the Cloud Native Computing Foundation (CNCF) and is now being advanced by contributions from multiple vendors. Much of that focus is on lowering the barrier of adoption for the platform, said Watson. Specifically, Spotify is working on a QuickStart for Backstage edition of the platform that is simpler to install, she said.

    In general, Spotify is trying to strike a balance between centralizing the management of DevOps workflows and the need to enable developers to define workflows that are natural to them versus ones that have been imposed on them, added Watson.

    It’s not clear to what degree Backstage will help fuel the adoption of a shift toward platform engineering to centralize the management of DevOps tools and platforms. The concept of a portal through which developers can self-service their own needs may not be new, but as an open source project, Backstage has made it simpler for many organizations to achieve that goal.

    Just about every DevOps team is now being asked to find ways to help improve developer productivity at a time when many organizations are trying to do more with fewer resources. Regardless of the motivation, however, it’s apparent that DevOps workflows are continuing to evolve and mature.

    In the meantime, DevOps teams would be well-advised to eliminate as many bottlenecks as possible before they negatively impact developer productivity.

  • How LinkedIn is Investing in Developer Productivity and Satisfaction

    How LinkedIn is Investing in Developer Productivity and Satisfaction

    More and more companies are beginning to examine the role developer experience has in improving engineering productivity and morale. And one company often referenced as a model for developer productivity engineering is LinkedIn—its engineering leadership has invested heavily into reducing time-consuming developer tasks and constructing an internal platform to gauge developer satisfaction on the tools they use.

    Engineers at LinkedIn recently shared how the company has invested in measuring developer productivity and happiness as well as their strategies for automatically cherry-picking commits. I also met with LinkedIn engineering leadership for a closer look at how the organization is working to improve the developer experience across its internal platform.

    Below, we’ll take an inside look at LinkedIn Engineering’s efforts to enhance developer happiness. We’ll explore their approach to improving their internal software development trends and consider the benefits LinkedIn has gained throughout the process.

    A Look at LinkedIn Internal Developer Solutions

    Productivity is challenging to measure, said Jared Green, VP of engineering, head of developer productivity and happiness at LinkedIn. So, the company opted to take a different approach by including happiness as a variable in the equation. Thus, they measure not only how fast a workflow is but continually monitor how enjoyable the process is to ensure developers have a delightful experience.

    “We don’t just strive for productivity, but for productivity and happiness,” said Green. And to his point, on-the-job satisfaction can have real-world results—on average, happy workers are 13% more productive, according to a University of Oxford study.

    LinkedIn now oversees a custom-built internal platform for evaluating the sentiment of developer tools. The platform, known as iHub, is a holistic listening channel to gauge developer satisfaction across various tools. It collects real-time qualitative feedback from users and correlates it with objective quantitative telemetry. It then surfaces this data in a UI dashboard for team leads and individual contributors to view.

    But there’s an art to engendering the trust required to collect accurate feedback, says Max Kanat-Alexander, principal staff software engineer at LinkedIn. For example, individual contributors need to be sure the data won’t be used for performance reviews. Once that trust is established, folks are more willing to give genuine feedback, he said.

    Benefits of Investing in Developer Enablement

    The benefit of centralizing developer experience metrics with a shared platform means that tech leads can make data-backed decisions on how to improve their DevOps processes. “It’s really about thinking about giving people insights versus giving them data,” said Green. The idea is that frontline engineers can rapidly investigate any metric to expose problems and see trends. “The optics have given leaders ways to improve various parts of developer experience,” he said.

    Through their investment into developer experience, LinkedIn Engineering has discovered and streamlined hangups in the Git flow, exposed inefficiencies in their code review processes, and fixed specific developer build times. LinkedIn Engineering reported it has reduced time spent on certain time-consuming developer tasks by 99.6%.

    To construct iHub, LinkedIn Engineering wrote its own front end. The hub pre-computes data dimensions and stores them in an offline data store, increasing speed, said Kanat-Alexander. The system uses a sophisticated survey technology to collect the data and hides the complexity of manual collection in a sleek dashboard.

    LinkedIn managers have already leveraged iHub data to identify macro trends and resolve specific points of friction. For example, Kanat-Alexander describes how one director noticed that developer build time was worsening in their organization. They were able to isolate it to a single developer who wasn’t using remote development, which was spiking the metric. Leaders then assisted in unblocking them.

    Takeaways For Your Organization

    Most companies could benefit from a UI like iHub, explained Kanat-Alexander. But, you really must have a large engineering organization to see the benefits of the work. Plus, up to 80% of the legwork is simply data integrations—this involves hooking into systems, cleaning up data and deciding how to measure certain metrics. “Whatever you can measure, you can improve,” said Green.

    LinkedIn Engineering has flirted with the idea of open sourcing iHub, but it’s a bit too custom to LinkedIn to be valuable to other enterprises. “There’s a lot of variance in build technologies nowadays, and large-scale engineering systems are bespoke,” said Green. Implementing such a dashboard also requires a deep understanding of developer personas and how people work, which can be entirely unique for each organization.

    Although other organizations can’t fork LinkedIn’s efforts, there are some takeaways that could help others invest in their internal DX. First, Green recommended starting with the fundamentals. “Having a core of understanding about what you’re trying to move the needle on is important, as is coming up with ways to talk about it consistently.” This forethought should help establish what you want to measure.

    Turning DX Metrics Into Action

    Studies indicate that more companies are seeking to implement platform engineering or similar developer productivity engineering initiatives. The end result of these efforts should be to empower people and ensure they are satisfied with their work and not just a cog in the system.

    On that note, it’s critical that there are mechanisms for action to happen on the data that is collected, said Kanat-Alexander. Someone needs to monitor the insights and make changes to improve the metrics over time. “Then you can win hearts and minds.”

  • How Developer Productivity Engineering (DPE) Enhances Software Delivery

    How Developer Productivity Engineering (DPE) Enhances Software Delivery

    Developer experience (DX) is in the zeitgeist, and for a good reason. Digital demands are increasing, yet the market faces cautious IT budgeting, workplace burnout, and high resignations. The idea is that quality developer experience can help keep the remaining talent happy and increase productivity. And organizations are considering many strategies for increasing DX, such as creating more usable interface interfaces, maintaining intuitive documentation and abstracting complexity with more automation and low-code.

    Another way to increase productivity is by slimming down the time it takes to test and deliver software. There are many potential hurdles in the way of deploying new code, and a cumbersome pipeline can easily take a programmer out of the flow. The practice of streamlining this toolchain is known by some as Developer Productivity Engineering (DPE). DPE focuses on improving developer productivity through accelerating DevOps processes, like CI/CD pipelines.

    I recently met with Hans Dockter, founder and CEO of Gradle, to understand the core tenants behind DPE. According to Dockter, the dialogue with the toolchain is a developer’s bread and butter, and optimizing this exchange is vital for quickly validating new ideas. Below, we’ll seek to understand what DPE is and how it might increase the pace of software delivery. We’ll also consider some methods for implementing DPE in practice.

    Roadblocks in the Development Toolchain

    Engineers are always experimenting with new feature development. “A developer needs to have a dialogue with their toolchain to see if their hypothesis makes sense,” explained Dockter. Yet, there are many potential barriers to instant feedback. For example, a toolchain may be comprised of code compilation, static code analysis, unit testing, performance testing, security testing and other checks. Running new changes through a CI/CD pipeline can take anywhere from a few seconds to minutes or hours. In his work, Dockter has even encountered teams that deal with a 24-hour feedback cycle time.

    Long wait times can be taxing as they demand users to switch contexts. Neuroscientists say that multitasking depletes glucose in the brain and leads to exhaustion. Similarly, Dockter argued that long waiting periods with the toolchain can take developers out of the flow and slow down the pace of software delivery. “You cannot have a good developer experience without good productivity.”

    Furthermore, he added that engineers often encounter untrustworthy signals from their toolchains. If testing suites produce too many false positives, for example, you can lose faith in the tooling altogether. This equates to a bad experience and may result in developers overlooking important signals that do matter.

    Understanding Developer Productivity Engineering (DPE)

    DPE is all about improving developer efficiency. And quickening the feedback cycle is one method to enhance developer productivity. According to Dockter, DPE applies a few strategies to streamline this feedback loop and shorten the timeframe:

    • Optimizing which tests are run: First, Dockter recommended only running tests relevant to the change at hand. Optimizing test selection can reduce bulky builds and significantly reduce the time it takes.
    • Caching: Caching is integral to any web application, so why not apply similar heuristics for the development pipeline? This could involve caching code that is not changed. “Changes are often incremental from one feedback cycle to the next. A lot of output is produced that can be reused,” said Dockter.
    • Predictive test selection: To automate test optimizations, Dockter recommended predictive test selection to understand which tests are sensitive to which areas of code. This would utilize an AI trained on release mechanics to help pinpoint what components the changes modify and, thus, what tests to run.
    • Test distribution: Another way to accelerate the pipeline is by distributing testing processing. Using multiple machines to test different areas simultaneously could greatly speed up the routine. Test distribution “is a modern approach to test parallelism that accelerates test execution by taking existing test suites and distributing them across remote agents to execute them faster,” wrote Marc Philipp and Hans Dockter in The Developer Productivity Engineering Handbook.
    • Monitor the toolchain: Lastly, it’s good to continuously monitor failure analytics to discover where the toolchain itself is causing trouble, said Dockter. On the side, CI/CD pipelines are not immune to security vulnerabilities and should be treated with the same security standards as other infrastructure.

    DPE principles have already been applied at DoorDash, LinkedIn, Netflix and other organizations.

    Benefits of Developer Productivity Engineering

    In the last few years, DX has moved from niche to mainstream, said Dockter. In fact, DX has even entered the C-suite, as certain companies have embraced the role of chief developer experience officer CDX). And with the emerging discipline of platform engineering, we’re seeing an even greater focus on streamlining internal DevOps workflows.

    And although platform roles may have been viewed as second-class engineers in the past, said Dockter, they are held in high esteem nowadays. “It’s as important as the other engineering work we’re doing,” he said. Developer productivity engineering seems to align with these principles, helping organizations manage the effects of an exponentially expanding code base. In the end, an investment in DPE, like platform engineering, could bring more satisfactory working conditions and accelerate the pace of software development.

    “DX is a transformative opportunity, but most companies invest incrementally. The economic benefits are transformative for companies developing infrastructure to get more output from their developers.”

  • The Impact of Developer Happiness on Productivity

    The Impact of Developer Happiness on Productivity

    Even in an era of unprecedented tech layoffs, most companies are still eager to find and retain top software developer talent. What’s more, many firms are discovering that they lack direct insight into their development teams’ needs and priorities. As a result, some of them are struggling to keep their developers happy and thus productive. A recent Zenhub report found, for the first time, a quantitative link between developer happiness and productivity, including what keeps developers in the same position instead of moving on to another job at the first sign of perceived trouble.

    Software Development Happiness

    The 2022 Software Developer Happiness report is based on a survey of 380 software professionals from a host of different organization types. In brief, the survey found that two of the biggest contributors to devs being unhappy in their roles were a lack of work/life balance and not working on what’s perceived as “quality work.”

    Even with a looming recession and thousands of layoffs, there remains a dearth of senior software development talent. For more junior talent, there will be more available than in previous, pre-pandemic years. As companies strive to do more with less, they still require development teams to build their products and/or the applications that drive their business. Setting up more junior teams for success via collaboration and productivity tools will be key to navigating this new environment.

    Given these findings, if organizations want to retain developer talent, they still need to make sure developers are working on meaningful projects and that they’re able to achieve that work in a way that balances the needs of the business with the needs of the individual.

    An ideal example of this phenomenon is the developer tool ecosystem companies make available to their teams. While the growth of this ecosystem has been a net positive for developers, it has also created a lot of tool sprawl and significant integration challenges.

    Less Time on Application Development

    Stephen O’Grady, an analyst at RedMonk, an analyst firm focused explicitly on software developers, talked a lot about this through a term he coined called the “developer experience gap.” He is referring to developers spending more time integrating tools than working on application development or application code. That integration work comes at a real cost. It means developers are spending less time on application development, are having to work longer hours or do the integration work off the side of the desk.

    The real bottom line to these survey results is that developers are happiest and stay at their jobs longer when empowered to focus on building code. This means spending less time interacting with management, attending meetings or resolving and integrating multiple solutions. The report’s results also emphasized the importance of work-life balance in encouraging developers to stay at their current job longer, while poor work-life balance accelerated the hunt for another job. These insights into developer retention are especially critical as, according to the report, 71% of developers haven’t decided how long they’ll stay with their current employer. The report also suggested that 33% of developers have stayed in a job longer than usual due to the pandemic, which could mean an increase in developer turnover when the pandemic comes to an end.

    Another key finding is that collaboration challenges are viewed as the biggest impediment to developer productivity. Delays in feedback result in lost productivity; nearly 70% lose a minimum of three hours per week per developer and 75% spend at least an hour per week on reporting instead of writing code.

    Finally, developers said their biggest priority is ensuring their software meets business demands, and most developers want high-performance productivity tools. In fact, 93% of developers believed these tools are critical to their success.

    Increase Developer Happiness

    So what can team leads to alleviate these issues? For both team leads and more senior management, the biggest way to increase developer happiness is simply to let them focus on coding. Developers like to showcase their skills, so encouraging them to work on interesting and impactful projects that challenge their skill sets is a great way to boost morale. Ensuring an appropriate work-life balance and paying the developers competitively are the other two recommendations for improving developer retention.

    Additionally, senior management should take another look at how they are compensating their teams. Financial compensation will always be a critical element, but we should expect to see companies shift their focus to programs and benefits that their employees truly need. Particularly given the somewhat chaotic year in 2022 and continuing in 2023, those in the technology industry will shift to valuing organizational stability over just a paycheck. An improved focus on mental health, conflict resolution and work/life balance will also be a big part of attracting the appropriate talent to an organization.

    The full report provides further detailed analyst recommendations for project managers, product owners, team leads and executives. The entire report can be downloaded for free here.

  • The Evolution of DevOps: Developer Productivity and Platforms

    The Evolution of DevOps: Developer Productivity and Platforms

    This article is part two in a series of three on the rise of platform engineering and its role in improving the developer experience. Read part one here.

    Developer experience is business-critical in organizations of all sizes and across all industries. In the first article of this series, I make the case that the cloud-native developer experience will be shaped and eased not only by platform engineering but also by the vital support of DevOps and/or PlatformOps teams. This flies in the face of the recent and somewhat controversial assertion that DevOps is facing extinction. In fact, it’s possible that DevOps is more important than ever, even if the role of DevOps has changed in the era of cloud-native development, supported by centralized developer platforms.

    Business stakeholders who depend on reliable, stable, scalable and secure software shipping fast and consistently understand the business case for an integrated DevOps team, and most developers and their teams understand the challenges of coding, shipping and running cloud-native software without the guideposts offered by a platform (and the DevOps team). The complexities of Kubernetes and microservices (and their contingencies) make getting to productivity difficult, which is why developer platforms are touted as the magic-bullet solution. But these platforms don’t build and maintain themselves, and the concept hasn’t quite reached the level of maturity at which developer platforms are available as commercial, out-of-the-box offerings.

    Developer Platforms: Who Paves the Developer Path?

    DevOps is not dead and claiming that it is ignores the need for the surrounding, supporting roles that pave the developer path. DevOps is evolving, in some cases into PlatformOps, and keeps workflows flowing and manages operations that support developers’ ability to ship their work into the world.

    Who paves the developer path? It’s actually a cooperative process between developers and DevOps/site reliability engineering (SRE) teams. In discussions with DevOps and SRE leaders about cloud-native development, one trend was a throughline: DevOps and SREs continue to play an instructive role in helping guide developers to realize the possibilities of self-service through supporting platforms.

    The level of full-service ownership this amounts to for developers varies depending on the organization and its goals. But the role of DevOps is still clear. For developers, there is a significant learning curve, and DevOps can help clear the way to the centralized developer platform. This platform, assuming all goes as planned, will not only improve the developer experience but also relieve DevOps teams of the firefighting that has been typical of their job until now. Paving the path provides an opportunity for DevOps/SREs to both develop better operational support mechanisms for developers as well as engage in more long-term and strategic operational work.

    DevOps Ways: Unlocking Developer Productivity via Developer Platforms

    Helping unlock developer productivity is one aspect of powering a positive developer experience. And the shift to a developer-first platform model reinforces the business commitment to the developer experience. It becomes defined by its optimized tools and workflows, which make up developer platforms. The platform approach also supports wider adoption of cloud-native development across larger organizations and broader industries beyond the more niche applications we’ve seen, thanks to clearer guideposts and abstractions.

    But becoming dev-first doesn’t kill off ops, which has been one recent point of contention. In fact, the three ways of DevOps continue to be critical:

    ● The First Way: Flow/Systems Thinking
    ● The Second Way: Amplify Feedback Loops
    ● The Third Way: Culture of Continual Experimentation and Learning

    Quoting industry luminary Gene Kim, “The First Way emphasizes the performance of the entire system, as opposed to the performance of a specific silo of work or department—this as can be as large a division (e.g., Development or IT Operations) or as small as an individual contributor (e.g., a developer, system administrator).” Essentially, it doesn’t matter who constructs the platform as long as they are thinking about the entire value stream, starting with customer requirements which, for an internal platform, are driven by developers.

    The Second Way is focused on creating right-to-left feedback loops. To quote Kim again, “The outcomes of the Second Way include understanding and responding to all customers, internal and external, shortening and amplifying all feedback loops, and embedding knowledge where we need it.” For platforms, this hints at embedding both developers in platform teams and ops in development teams.

    The Third Way is focused on creating a culture that fosters two things: Continuous experimentation, taking risks and learning from failure and understanding that repetition and practice is the prerequisite to mastery. The platform you build today won’t be the platform you need tomorrow. This is why the ‘big bang’ approach to building platforms doesn’t work. Think big, start small and iterate fast. This is something DevOps is designed to do.

    In supporting the cloud-native paradigm, DevOps is far from dead. It’s a shifting discipline that involves a focus on centralizing workflows and infrastructure to improve the developer experience and reduce their cognitive toil. This toil stems from developer guesswork, and DevOps is best positioned to remove that obstacle. If we concede that developer experience is central to business success, and devex depends on being able to code, ship and run quickly and safely, DevOps is the fixer who enables crucial self-service access for developers and, as we will explore in the third and final part of the series, “platforms” the developer experience.