devopsy.kinsta.cloud

Tag: devX

Empowering Developers Fuels IT Resilience and Business Transformation
Developers are feeling the brunt of global economic pressures on their organizations to move digital transformation projects forward while having to do more with less. Adding to this pressure is the explosion of technologies like generative artificial intelligence (generative AI) and edge computing, which have made infrastructures more interesting and possibly more complex. The overall result is an increased mental load for developers tasked with bringing innovation to life while minimizing all the added complexity. And it’s DevOps teams who are carrying the weight of ensuring seamless integration, deployment and automation of new technologies. It’s incumbent upon IT leaders to give developers and DevOps teams a simplified, trustworthy data architecture to ease this burden if they want their modernization efforts to thrive.

It’s a difficult juggling act IT leaders know all too well — controlling costs and improving efficiency while increasing agility and resiliency. Management, budget and technology challenges have been causing digital transformation projects to be put on pause to avoid potential drawbacks or failures. In fact, 68% of organizations facing modernization challenges were forced to push digital transformation goals back by more than three months, with delays costing organizations $4.4 million on average.

Despite the hurdles — many of which were brought on by the COVID-19 pandemic — enterprises continue to focus on modernization: Nearly 60% said their key digitization goal is to improve business resilience and add AI-powered efficiency in the face of the evolving global economy. Recent research revealed that 53% of executives have already deployed some form of generative AI, with 45% forecasting that integration of automation and AI tech will catalyze a major transformation in their industry within the next five years.

The call to empower developers and DevOps teams is loud, and IT leaders should heed it.

Putting Developer Empowerment at the Top of the IT Agenda

Developers and DevOps teams must constantly adapt, from keeping up with changing market demands and customer expectations to navigating technology stack intricacies across a myriad of platforms, tools and frameworks. They also need to stay updated on the latest security practices throughout the development life cycle. Through it all, the pressure to innovate rapidly looms large.

Given their central role in today’s business, empowering the people who build and run modern applications must be a top IT investment priority. These investments have a synergistic payoff. They not only strengthen developers and DevOps teams, but the entire business reaps the benefits:
- When given the support and tools they need to successfully embrace new technologies and create new services, developers are empowered to take on new projects, implement new technologies and take advantage of growth opportunities. For example, cloud-based solutions, such as database-as-a-service (DBaaS) and containers-as-a-service (CaaS), offer developers vast opportunities to enhance their agility and efficiency to drive competitive advantage for their organization.
- Additionally, low- and no-code platforms, AI coding assistance and serverless computing allow IT to create opportunities for other business units to build their own services. This reduces reliance on developers for simpler tasks that line-of-business teams can accomplish themselves, freeing developers to focus on expediting innovation and helping to increase productivity across the organization.
Freeing Developers to Innovate With AI Increases Their Productivity

IT spending on AI is sure to evolve over the next few years. IDC predicts generative AI spend will reach $143 billion in 2027. Gartner recently stated that “while GenAI has not yet had a material impact on IT spending, investment in AI more broadly is supporting overall IT spending growth.” IT teams are working on their AI strategy and still need to better understand the role of generative AI or large language models (LLMs) before fully adopting them across the business. However, if one thing is clear to IT leaders today, it’s that AI can make developers more productive and speed up the pace of software development.

Furthermore, with AI, software development can be more efficient, accurate and adaptive, leading to faster development cycles, higher-quality applications and better user experiences. AI tools can assist developers in writing complex code, detecting and fixing issues faster and automating the testing process. AI can also offer many ways to enhance the overall DevOps process by automating repetitive tasks and analyzing workflow data to optimize processes.

As organizations aim to modernize and take advantage of generative AI, IT leaders should empower developers and DevOps teams to use it to simplify how they develop, deploy and run applications. By prioritizing the adoption of new technologies, such as cloud-native IaaS, AI, edge, mobile, serverless and low- and no-code computing, IT teams can help make DevOps teams more agile, cut down on costs and speed innovation.
February 8, 2024
Can Improving Developer Experience Actually Reduce Costs?

From platform engineering to AI, many new DevOps initiatives aim to improve internal developer experience (DX). Developer experience is essentially like user experience but considers the experience a developer has with a framework or tool. The promise is that quality DX creates a more satisfied workforce, reducing burnout and avoiding employee churn. But can improving developer experience also reduce costs?

I took to LinkedIn with this question, and the response was a resounding “yes.” In today’s lean tech climate, you might think that making the case to invest in employee satisfaction is a tough sell. But, it turns out that developer experience has significant ripple effects that benefit the business in diverse ways, making it a lucrative opportunity for technical leadership.

Developer experience contributes to outcomes like better efficiency, easier onboarding, less re-engineering, reduced overhead and more, which all — indirectly, granted — can reduce costs. Below, I’ll outline some of the ways developer experience can affect the bottom line, featuring viewpoints from various sources across the field of tech.

Improved Efficiency = Dollar Savings

The most obvious impact of enhancing developer experience is that improved efficiency can equate to dollar savings. For a concrete example, consider an API that provides useful error code responses and explains them within a developer portal. This saves developers time and money, said Brandon Boyd, product manager at Tekion. “Otherwise, they will have to guess about error codes and implement improper code, which requires rework,” he said.

With solid DevOps practices, a release that might have taken three months with manual processes could take a single sprint, said Anna Daugherty, director of product marketing, Opsera. “This leads to expensive development time saved while simultaneously getting the release to market faster to improve customer satisfaction and reduce churn,” she said.

Better Cycle Times Reduce Cost

Reduced friction can also lead to reduced cost. Specifically, better developer experience around areas like provisioning, scaling, and security can help things run more smoothly, equating to development and tooling efficiency, added Daugherty. “Taking out the guesswork and human error from development can save money on infrastructure, redundant tool costs and time costs,” she said.

Improving developer workflows, a practice some call developer productivity engineering, can have tangible outcomes that reduce costs. “Developers need flexibility and support from the right technology stack to be successful and deliver on quality work for overall business success,” said Dana Lawson, senior vice president of engineering, Netlify. “Investing in a cohesive workflow using composable web architecture streamlines processes to enable developers to focus on the higher-level thinking their projects need, and therefore cut time and budget spent on busywork.”

Good developer experiences also have minimal context switching, which can further reduce cycle time. “Forcing developers to toggle between various screens, applications, and docs inhibits deep work and focus and directly impacts how long projects can take and even the quality of the work,” said Isaac Nassimi, SVP of product, Nylas. Removing friction in the developer workflow can help launch projects faster, “creating longer revenue-generating timelines and opportunities,” he said.

Less Turnover and Onboarding

Developer turnover and onboarding can be expensive. LinkedIn reports that for each employee lost, the cost to the company could be up to 250% of their annual salary. Better internal developer experience can improve employee retention, which saves significant expenses. “It costs to hire a developer, and it costs to bring a new one up to speed,” said Andrew Cornwall, senior analyst, Forrester. “Happier developers are less likely to leave.”

But instilling a good reputation amongst developers has other side-benefits, Cornwall explained, such as attracting more first-tier, productive engineers. Developer retention also leads to better familiarity with the code, aiding debugging efforts and reducing human error. “Happy developers who have been there for a while start to understand what the goals of the team and the business actually are,” he said. “They can align what they do to satisfy a greater outcome.”

Reduced Overhead For Support

Another outcome for software products with good developer experience is that they are more self-service, meaning developers are more empowered to find the information they require to do their work. This, in turn, lowers the need for manual support and reduces labor costs.

Daan Stolk, co-founder, Alphadoc.io, recounted how his team at a previous company tracked whether support tickets could have been prevented with the right information architecture up front. He estimated that over 50% of cases could have been solved with the proper documentation and resources. As you can imagine, this finding led to a big overhaul of their developer support materials. “Ultimately, this resulted in customers not having to wait for responses to their questions and becoming more self-sufficient,” he said.

Less Re-Engineering

Developers make up an increasingly high expense on the balance sheet, and forcing them to re-engineer code is wasteful. One way to avoid re-engineering is to have better practices around reusable interfaces. For instance, GraphQL is proving to be a helpful layer to aggregate disparate data sources and federate a graph across an organization, making data retrieval more efficient.

“Reduce the time it takes [developers] to do recurring tasks by 30% or 40%, and you are talking about millions of dollars in savings annually,” said George Snowflack, director of central U.S. & LATAM, Apollo GraphQL. “This is why so many of the Fortune 500 have moved to a federated GraphQL architecture, because of its ability to compose a modern data access layer just one time, and then reuse it infinitely across any apps or clients on the front end.”

More Accountability and Responsibility

When employee needs are respected, they tend to feel more kinship with their internal community and take on additional accountability for their actions. “When a company’s developer experience promotes developer ownership, developers are more likely to take responsibility for their cloud environments, including cost optimization,” said Brandon Turner, VP of engineering, Kion. “Developers that feel empowered are much more willing to take accountability for their actions, including optimizing costs.”

Access to a Wider Talent Pool

When software is more usable, more people can participate, thus lowering the barrier to access and reducing the need for high-cost resources. “For some, this could include analysts moving into the developer role creating new efficiencies,” said Rob Koplowitz, former vice president, principal analyst, Forrester. “For the more intrepid, it could enable business developers that could change the paradigm significantly,” he said. However, a citizen developer culture must involve the proper controls around areas like change management, governance, and guardrails.

Furthermore, internal education costs are reduced with good developer experience. “The cost-savings value of prioritizing the developer experience is that companies do not have to make investments in continued education or hiring new individuals to help build upon new skills,” said Neil Kanungo, VP, product-led growth, KX. “Conducting in-person or costly training exercises can be viewed as an expansion if organizations have the time and budget, rather than a necessity.”

So, How Do We Get There?

It’s clear that improving DX can reduce expenses, especially regarding reduced labor costs. But how do you go about building out experiences that developers love? Well, it’s important for technical leadership to clearly understand what positive developer experience improvements actually look like. “These improvements should include introducing self-service mechanisms, removing friction, making educational training simplified and more accessible, and providing free access to community resources and support,” said Kanungo.

Lastly, leaders shouldn’t expect developers to optimize their costs without the proper support. Instead, cost savings will hinge on giving developers more visibility into their applications, especially for complex shared cloud environments. “If a development team can’t tell what cost inefficiencies are related to their application, they are less likely to optimize those costs,” said Kion’s Turner. “Simplifying the developer experience by giving development teams isolated environments that they own promotes responsibility for the health of those environments,” he added.

Furthermore, helpful tools will be required to move developer experience initiatives forward. Jon Peck, senior manager, developer relations and enterprise advocacy at GitHub, explained how DevOps practices, such as AI pair programmers, cloud IDEs, automation, asynchronous communication formats and shift-left security tools can work together to improve developer experience and indirectly bring cost-savings. The latter, developer-first security, could have real tangible monetary benefits since fewer vulnerabilities in production means fewer costly security incidents.

Lastly, as leaders seek to optimize their IT departments, much thought has been placed on ways to measure software developer productivity lately. Yet, most savvy executives view this as a red herring. While taking account of some development metrics is helpful, relying too heavily on minute analytics, such as individual commits or bug fixes, can negatively affect developer experience.

Final Thoughts: Good DX = Less Humanpower = Cost Savings

The most obvious outcome of improved developer experience is that less energy and time are expended. Developer cost per hour doesn’t have as much of an economic impact. This impact is apparent in both bustling and lean economies. “In times of expansion, improved developer experience can improve new-hire onboarding costs,” said Kevin Swiber, API strategy lead at Postman. “In times of contraction, developer experience can help improve cycle times as folks do more with less.”

It’s also evident that developer experience is especially important for API-first strategies. Better usability around API gateway management, for example, can increase simplicity and enable teams to allocate resources elsewhere, explained Abdallah Abedraba, developer relations, Zuplo. Mark Rovetta, senior programming writer at F5 Networks, also added that improving the quality of API documentation can reduce costs substantially since it enables deployment fluidity and aids learnability.

So, with all that said, listen to your developers and their needs. You might learn a thing or two. And save a buck or two.

January 29, 2024
Nerd/Noir Allies With DX to Improve Developer Productivity

Nerd/Noir today announced it has partnered with DX, a provider of a platform for measuring developer experience, to identify areas where organizations can improve developer experiences in less than six weeks.

The consulting firm plans to leverage the DevEx 360 platform created by DX to survey developers before recommending a plan.

Nerd/Noir CEO David Laribee said that approach will make it simpler for DevOps teams to pinpoint where changes to workflows will have the most impact on 25 different key performance indicators (KPIs).

In addition, DevOps teams will be able to compare their results against more than 120,000 anonymized data samples collected across multiple industries and sectors.

There’s a lot of focus on developer productivity these days, largely because more organizations realize the extent to which they have become dependent on software to drive revenue and improve profitability. The challenge is organizations can’t afford to hire an unlimited number of developers, so many are now embracing platform engineering as a methodology for managing DevOps workflows at scale.

Most DevOps teams track metrics, but they are generally focused on software engineering issues rather than actual developer productivity. Measuring developer productivity tends to be a less exact science. Once upon a time, an organization might have tracked the lines of code being written, but the total number of lines of code written may not be especially good. In more recent times, metrics have been developed that, among other things, keep track of how much time developers spend actually coding versus maintaining their software development environment.

The issue that organizations are contending with is that more responsibility for managing everything from development environments to provisioning and securing cloud infrastructure has shifted, and the cognitive load that each developer is required to carry has increased. Every minute developers spend on these tasks, however, is, in theory, one less minute developers are potentially spending writing the business logic that drives an application.

Of course, there’s no way developers are going to write business logic for eight hours straight every day, so there are maintenance windows. However, application development is as much art as it is science. No one knows for sure when inspiration might strike, but if developers are busy maintaining code that they created to provision infrastructure, the less probable it becomes for some flash of brilliant insight into how an application might be made better is likely to occur.

DevOps teams need to strike a delicate balance. Developers like to be able to experiment with new tools and platforms, so any approach to platform engineering that smacks of totalitarianism will be resisted, and IT leaders need to proceed with caution. If talented developers start heading for the exits, IT leaders will find it difficult to replace them because great developers, even in an economic downturn, are still difficult to hire and retain. The challenge and the opportunity are to convince developers to embrace changes to workflows based on their input versus imposing one that benefits the DevOps teams more than the developers those teams are supposed to support.

January 9, 2024
Should You Measure Developer Productivity?
A recent McKinsey article entitled ‘Yes, you can measure software developer productivity‘ has got the software developer community talking. And the general consensus is they’re not happy.

Most software developers are not enthusiastic about the prospect of having their individual performance metrics monitored. “Anyone who attempts to measure software in some sort of scientific way is just doing the wrong thing,” said YouTube personality ThePrimeTime. Dave Farley of Continuous Delivery even goes as far as to call the McKinsey report “harmful dribble.”

This debate arises as developer productivity engineering (DPE) is gaining traction as a means to improve developer performances and, perhaps, in response to employment landscape shifts like the Great Resignation, which saw developers and DevOps pros leaving their roles. Companies like Spotify, LinkedIn, Netflix and others are also investing in internal developer platforms (IDPs) to increase developer productivity and satisfaction amid a limited talent supply.

Alongside these ambitions, much has been written about how managers can measure developer productivity in terms of qualitative metrics, like developer satisfaction, as well as quantitative metrics, like number of commits or story points, deployment frequency or failure rates. But can tracking such metrics deliver tangible results? Or do they go too far?

Below, we’ll consider whether you can actually measure software developer productivity. But more than that, we’ll evaluate whether this is a meaningful tactic with desirable outcomes.

Ways to Measure Development Productivity: DORA

First, let’s look at some of the standard techniques to measure development productivity. The DORA metrics, produced by the DevOps Research and Assessment (DORA) team at Google after years of research, identified four key metrics:
1. Deployment frequency: How often you ship changes.
2. Lead time for changes: The time between a commit and it reaching production.
3. Change failure rate: The percent of releases that fail; downtime, worsened service or rollbacks.
4. Time to restore service: The average time it takes to respond to an issue, also known as mean-time-to-recovery.
These metrics could be helpful indicators of a software development team’s overall agility and health. They can signal bottlenecks in the CI/CD process or highlight where too much time is spent remediating issues, encouraging positive changes. Solving these root causes could all improve a team’s productivity.

Going Beyond DORA: SPACE

DORA also added reliability to the list. That’s understandable, given the interest in building reliable systems. But things start to get a little more complex when SPACE enters the equation.

Proposed in a 2021 paper by GitHub researchers, SPACE augments DORA with the following attributes:
- Satisfaction and well-being
- Performance
- Activity
- Communication and collaboration
- Efficiency and flow
Metrics like satisfaction or communication and collaboration are pretty subjective. Plus, it can be challenging to gather this data and encourage engineers to speak honestly in surveys. Measuring the activity of individual members, like the number of issued closed or pull requests made, isn’t exactly tied to end value and could even produce a negative psychological effect.

“Consequently, teams can become fixated on them, as seemingly positive changes are relatively easy to achieve,” wrote James Walker. He adds that SPACE still doesn’t tell you why measurements have value—furthermore, it lacks actionable information and might be tricky to implement, given developer pushback against performance analysis systems.

Opportunity-Focused Metrics

The McKinsey report adds to the mix what it calls “opportunity-focused productivity metrics,” which include inner/outer loop time spent, a Developer Velocity Index benchmark, contribution analysis and a talent capability score. (It’s not totally clear how these metrics can be computed). It then organizes all these metrics into a framework that further segments measurements into system, team and individual levels.

While some believe in the framework’s legitimacy, many commentators don’t see the practicality of implementing such a framework in practice. “Introducing the kind of framework that McKinsey is proposing is wrong-headed and certain to backfire,” wrote the PragmaticEngineer.com. “The report is so absurd and naive that it makes no sense to critique it in detail,” wrote Ken Beck.

Things to Avoid With Developer Productivity Metrics

Apparently, developers are very weary of being measured. And given the recent backlash, it seems like overreliance on productivity metrics could negatively impact the engineering culture. So, engineering leadership should be careful when implementing these sorts of tactics. Here are some anti-patterns to consider.

Don’t make it about individual performances. Metrics like DORA have become standards for measuring the efficiency of software teams, but they shouldn’t be applied at the individual level. “Measuring software development in terms of individual developer productivity is a terrible idea,” said Dave Farley. Technology development is more of a collaborative process; performance metrics should reflect how the team operates.

Don’t measure developer productivity in isolation. On that note, performance metrics shouldn’t be judged in isolation. Issues with failures, for example, often depend on contexts outside of an individual developer’s control. At the same time, it can be hard to correlate individual developer contributions to end customer satisfaction.

Don’t create an opportunity to gamify productivity systems. Leadership shouldn’t directly tie a developer’s salary, reputation or position to whether or not they hit certain metrics. If productivity systems carry this much weight, they could become gamefied.

Don’t put in more effort than it’s worth. In tech, where there’s hype, there’s money to be made—and a host of vendors ready to hawk monitoring tools. What’s more, to enact these productivity measurement enhancements, McKinsey noted that “most companies’ tech stacks will require potentially extensive reconfiguration.” Devoting many engineering resources to monitor engineers just seems like a big pill to swallow.

Don’t put too much faith in metrics. Lastly, metrics only show one side of the picture. They are only data points and can’t always depict what it’s really like on the ground. Furthermore, qualitative responses also might be skewed due to reluctance to speak up.

Remember Goodhart’s Law and Focus On Quality

Personally, I believe that measuring things like developer productivity, efficiency, experience and satisfaction does have some merit for some businesses. Most teams are now working asynchronously, and metrics help leaders take the pulse of a team’s performance, even if they are all remote workers.

It’s also nothing new. Leadership has been attempting to measure developer productivity for years. But, these metrics often lack context and come with many caveats to consider. Thus, they shouldn’t be given a huge seat at the table.

I like this ‘law’ from British economist Charles Goodhart, which is colloquially summarized as “when a measure becomes a target, it ceases to be a good measure.” In other words, when you start working for the metrics, the engineering culture and overall code quality might decline. This matters, since a separate study found that increases in code quality tend to be followed by an increase in developer productivity.

So, focus first on establishing code quality and, hopefully, productivity will flow.
September 18, 2023
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…)

June 15, 2023
The Metrics Disconnect Between Developers and IT Leaders

A survey of 350 software developers found a majority (91%) of respondents are unhappy with the actual metrics leadership teams are measuring.

The survey, conducted by Atomik Research on behalf of Uplevel, an enterprise intelligence platform provider, found the top metrics developers say should be tracked include hours worked (52%), work allocation (49%) and the amount of time they have to focus on writing code (46%).

Unfortunately, the survey also revealed more than half of respondents (56%) reported that the CTOs that lead software development efforts make significant strategic decisions without realizing the negative impact on their team. They also often move people around on projects or tasks without knowing the full implications (51%) and overwork developers (44%).

Just under a third (30%) noted their engineering leaders rely solely on gut feelings to measure the effectiveness of their teams, while a third of respondents observed most engineering roadblocks go unnoticed by leadership.

Additionally, 96% noted that not knowing what their own leadership team is working on is detrimental to the larger team.

Christina Forney, vice president of product management for Uplevel, said many CTOs clearly need to be more engaged. Developers don’t mind being measured, but they clearly want to be evaluated based on metrics that matter, she added.

Managing software development teams has become a lot more challenging in an era where many developers are working remotely. IT leaders can no longer manage by walking around as easily as they once did, said Forney. Aligning workflows across a highly distributed team of developers is a challenge no matter how many communications platforms are used.

Surprisingly, the Uplevel survey found more than half of respondents (54%) said they feel more productive in the office. More than a third (35%) also said they preferred some form of synchronous communication to engage with other members of their team versus 27% that preferred some form of asynchronous communication. A total of 38% said they preferred a mix.

It’s no secret that despite long-standing commitments to automation, there are still a lot of manual processes in DevOps workflows that create bottlenecks. In an uncertain economy, however, there’s a lot more focus on developer productivity, so eliminating DevOps bottlenecks has become a major priority. The challenge is those bottlenecks are not as apparent to senior IT leaders, many of whom may have simply become inured to them over time.

Regardless of how bottlenecks occurred, DevOps teams would be well-advised to reevaluate the metrics they track. Mean-time-to-recovery (MTTR), for example, is not as important a metric to the business as the amount of quality code that finds its way into a production environment.

In theory, all the data required to track more meaningful metrics that could improve productivity already exists in the tools and platforms DevOps teams use to build and deploy an application. The challenge has been finding a way to automatically surface that data without adding yet another bottleneck to a DevOps workflow.

May 25, 2023
Improving DevX Gives Your Business a Boost
As organizations transform and grow, different methodologies and development tools can come together, creating an extra level of complexity for your mainframe application development teams. In a perfect world, developers would be able to focus on delivering solutions without worrying about all the infrastructure necessary to make that happen. Building a better developer experience, or DevX, can make that a reality.

DevX is about meeting developers where they are, at every stage of their career, delivering compatibility with and connectivity to the tools and devices that they want to use so they can focus on what they do best: Coding and releasing high-quality mainframe applications faster and more frequently and fostering better productivity and more innovation.

Automation is integral to removing friction for developers. A modern integrated development environment (IDE) with built-in automation allows developers to find and manage code more efficiently and with greater quality and move quickly and easily from coding to editing to debugging to testing.

Modern tooling can simplify and accelerate how developers work by giving them a visual representation of their code layout in a single-pane-of-glass view. They can move quickly in a natural, easy way with more information at their fingertips while built-in automation offers assistance at the right moment without getting in the way.

This can seem difficult when dealing with mainframe application development and longtime mainframe developers who are still working with tools from the 1980s haven’t directly benefitted from the intervening decades of improvements. What they might not realize is that the improvements made for other platforms are available to mainframe developers, too. By engaging them in your DevX modernization efforts, you can improve their experience—and that of their team members.

Elements of a Productive Mainframe Developer Experience
- A modern DevX adopts flexible agile processes that give developers predictable capabilities and enable smaller, iterative changes with faster feedback. It also syncs distributed and mainframe development teams to foster greater collaboration for additional process improvements.
- A better DevX is platform-agnostic, creating a development environment where developers can focus on the functionality of the applications they’re building instead of the deployment mechanism, leveling the playing field for every generation of developer.
- With an improved DevX, developers can achieve the full potential of DevOps. Implementing DevOps for source code management (SCM) functions allows developers to understand the scope of any changes needed before they start coding, which helps speed approvals through concurrent work streams.
- The single biggest boost to productivity—and an integral component of DevX—is shift left automated testing that enables developers at all skill levels to test new code immediately and find and fix bugs earlier in the development cycle when they’re easier to fix—and before they reach the end user. Continuous testing also automatically prepares test data within the DevOps toolchain.
- An improved DevX delivers operational insights, so developers aren’t just catching issues but also understanding and prioritizing them, working hand in hand with the operations team to make the overall system better. It also empowers newer developers to address and correct any issues that arise in legacy code without poring over hundreds of modules to find what they need to improve. DevX tools work together to give developers an opportunity to leverage operational data in a whole new way.
Once you have the tools, your mainframe developers need to be supported by a culture and education that teaches them how to use them and understand the benefits they offer. If you implement new tooling that nobody will use, the transformation is for naught. It’s important to start with the user experience and find the right tools to address it rather than starting with a tool and forcing its use just because it’s new. Continuous improvement is an important part of this; otherwise, you could bring the mainframe developer experience from the 1980s up to today’s standards only to have it freeze in place. This is why metrics and analytics are so important.

As you speed up delivery, you also want to make sure the quality improves. With an improved DevX, you’re consistently finding defects earlier in the life cycle, which results in safer, more efficient delivery of better-quality code. By tracking velocity with metrics such as user stories delivered in one sprint, you can gauge how those changes are making a difference. You can also demonstrate how automation helps eliminate human error, increases code drops, and improves business agility.

If you’re giving your mainframe developers everything they need to do their jobs easily and more efficiently, they’re exponentially more likely to adopt the tool and advocate for it—because a better DevX improves the day-to-day employee experience for longstanding and next-generation developers. By removing the drudgery of tasks that take developers away from writing code, you’re unleashing their creative and enabling them to achieve even greater levels of innovation—and you’re also improving your hiring and retention practices.

Improving the mainframe DevX pays dividends across your business, from your developers to your customers to your stakeholders, so you can bring more new features to market faster and enable a competitive response for revenue-generating solutions. The mainframe is here to stay. Make sure you’re building a modern development environment that empowers your developers to respond nimbly in the face of change and make change your advantage.
May 22, 2023
Platforming the Developer Experience
This article is part three of three on the boom in platform engineering and its role in supporting a streamlined, positive developer experience.

In a perfect world, the developer experience would be on that is completely free of obstacles. In the previous articles in this series, I argued that supporting and improving the developer experience is a critical business requirement. To continuously improve and keep up with the constant change that typifies the cloud-native development landscape, platform engineering is–at least for now–the golden path to reducing developer toil and increasing productivity.

I’ve also countered the controversial idea that DevOps is on life support because centralized developer platforms eliminate the need for DevOps. If anything, DevOps and developers share a symbiotic relationship, and the developer platform is where their functions converge. In this third and final article of the series, I will explore this relationship, examining the considerations for how the developer experience is “platformed” and by whom.

Optimizing Developer Experience: The Circular Economy of the Developer Platform

Let’s put it this way: The more relevant and useful the developer platform, the likelier the developer is to use it. If it reduces toil, cognitive load and makes shipping software easier, the developer has more time to focus on their core task: Developing features. With intuitive, self-service workflows and all the tools developers need, they rarely, if ever, have to think about ‘the how’ of getting their software into the hands of users. And this works if and when an organization does at least a couple of things right:
- The organization prioritizes the developer experience and empowers other parts of the organization to answer the question, How can we create the optimal developer experience?
- The organization puts resources behind understanding and building the best developer experience–and that’s where both the developer platform and DevOps teams as “fixers” ideas emerge.
Does this mean the “optimal experience” can’t be optimized? Does that mean developers cannot have input into their own (or more general) developer experience(s)? No. In fact, part of what makes the developer platform idea compelling is that developers don’t have to weigh in or make decisions on the platform or tooling. Still, it’s possible to let them have that freedom if the team or organization wants to. Bottom line: There is no one-size-fits-all developer platform any more than there is a single developer experience. This is why DevOps, along with PlatformOps, is an ideal complement to facilitating the “circular economy” of the developer platform. The platform is unlikely to stay static. And to keep it dynamic and responsive to the changing needs of the developer teams using it, the DevOps teams of the future can proactively remove, recycle, repurpose and restructure the way the platform runs and what tools are available in it, automating and evaluating … almost like a feedback loop on the platform itself.

Your Developer Platform is the Golden Path to Developer Productivity

The developer experience is built around the tools and workflows developers use and, in the case of a developer platform, the tools and processes you define and provide, i.e., a “golden path” to productivity.

Whatever that platform includes, it will demand that you answer questions about what tools, processes and best practices will be most effective for delivering the optimal developer experience. For example, what and how much should you build yourself? How should the platform be assembled to best serve the needs of your developer team? What is the most effective configuration? How much freedom can or should be given to your developers, depending on your business goals and the security, stability and scalability requirements of your organization and products?

Boiling down the route to the golden path, there are three critical points to help guide the creation of an effective internal developer platform:
- Treat your platform as a product. This is key to reducing cognitive load and paving the way to shipping software fast and safely. This also means that you are guaranteed to have an MVP and alpha, beta, etc. version of the product–and subsequent versions serve their purpose temporarily but are always works in progress.
- Realize you can’t have good DevX without good UX and develop accordingly.
- Focus on workflows and tooling interoperability; that is, a developer(-led) control plane. What is going to work for developers in practice to ensure that they can focus on key deliverables? How will you gather intelligence to discover when it’s time to make changes to the platform? Who will be responsible for this?
Paving and Using the Golden Path Developer Platform Simultaneously

Developer platforms can significantly improve developer productivity and the overall developer experience. But you can’t just build a platform and hope for the best without seeking developer input or understanding how developers work. Nor can you build a platform and decide it’s finished and forget about maintenance, enhancements and inevitable change. Developer platforms don’t exist as one-and-done items on a checklist and are themselves productivity tools that are in a constant state of flux.

Misunderstanding why you would platform the developer experience in the first place defeats the purpose.
February 21, 2023
Bridging the Developer Experience (DevX) Gap

They say our past experiences have an impact on how we view life and our general outlook. Routine behaviours and patterns become a program that we follow day in, day out. We stop using our minds to their fullest potential and become trapped in unquestioning, continual cycles of process and emotion.

The same could be said of our experiences in the present—our worlds shaped by the environments around us. The people, practices, tools and culture. Only by challenging these accepted patterns can we start to think about changing our mindsets.

DevOps is a mindset; a way of forming an agile relationship between development and operations teams to speed up delivery of software to support business operations and improve customer experience. By and large, it has been successful. Companies react to change more effectively; software is developed and deployed swiftly. It has become a necessity across most organizations.

There are challenges, as we all know, however. The State of DevOps Report 2021 found that 83% of organizations are implementing DevOps practices, but most are still failing to scale adoption. It’s a situation that hasn’t changed for four years. Why? Among other things, the report states there are too many silos, not enough skilled people, a saturated market with too many tools—and a culture that prohibits scale.

Given that the end goal of DevOps is to generate untrammelled innovation across an organization, getting the culture right is critical. Developers need an environment where they have the confidence to innovate and contribute back to their community, help grow the business, improve their skill sets and further their careers without being limited by the people, practices and tools around them.

Above all, it’s about creating the best possible developer experience (DevX) in which to thrive.

The Developer Experience Gap

Stephen O’Grady at Red Monk, the developer-focused analyst firm, originally wrote about a DevX (developer experience) gap in this post back in October 2020.

Stephen likened the experience you get from an iPhone to the expectations of developers. The iPhone’s closed SDK created an environment that allows all developers to work in a consistent way. Functions are tightly integrated so that, for example, it would be easy to ensure the music volume lowers when you receive a call. A basic function, but one that we expect to work seamlessly with any app we install.

Since then, developers have been served a vast array of tools and services with more and more software arriving on a daily basis. The challenge is that, where the phone and music player teams were controlled in a way that would make them work well together, modern development infrastructure doesn’t have that capability. In most cases, the toolchain is a “patchwork quilt” of products and services from different suppliers. And it is up to developers to build and maintain that quilt.

This means that developers are being forced to take time away from writing code—the reason why they are employed in the first place—to dedicate valuable time and resources toward understanding and managing issues associated with highly complex, multi-cloud toolchains that are often being held together by nothing more than sticky tape and string.

In other words, the very same market that is telling developers they can have anything they want to do their jobs more efficiently is simultaneously telling them that piecing the whole thing together is their problem. This is the gap for developers: It’s a gap between expectations and current reality. And a bridge across that gap needs to be built for organizations to get the most out of DevOps.

Delivering the DevX Factor

Attracting the best people is about showing that the experience they will have in your organization is both rewarding and liberating, so expecting developers to spend the bulk of their time not developing is clearly not an optimal experience. Creating better DevX will not only influence your ability to attract new people but enhance your ability to hold on to, empower and upskill the teams you already have.

Where to start? Well, contrary to popular belief, you don’t need an army of DevOps engineers to reach your goals. Instead, you need to empower your existing teams to reach their full DevOps potential, supporting their progress with the right tools and training for their experience and role.

As with any work culture (remote or hybrid), the importance of knowing where to find what you need and how to collaborate with other teams has never been so important. Tooling is a good place to start. DevX is affected by the tools they use, so organizing them in a way that helps with the culture is a step forward. In a multi-cloud, multi-vendor environment, there isn’t going to be one tool that does it all so the key is to allow teams to use the tools they love and automate as much as possible to remove the repetitive tasks.

Automation is also a critical element in the race to reduce time-to-market and improve quality where concepts such as shift left are adding complexity and increasing the responsibilities piled on developers. Having access to testing automation in a consistent way will improve the overall experience for DevOps teams.

And finally, think about starting your DevX journey by using a self-service platform, where information, tooling and automation can be centralized and made available to developers on demand. For overworked specialists, access to a platform that connects to any tool and creates an on demand environment that automates much of the repetitive work will create more time for them to do what they were originally employed to do: Develop.

December 2, 2021