devopsy.kinsta.cloud

Tag: developers

Navigating Passkeys: Challenges, Pitfalls and Considerations for Developers

Earlier this year, the FIDO alliance announced the launch of passkeys, a much anticipated, passwordless authentication factor many consider the long-awaited death knell of passwords.

In many ways, it is. Already, the tech sector’s biggest players have jumped on board, with Apple, Google and Microsoft all announcing support for passkeys in their latest products. And general corporate enthusiasm for a password alternative has never been higher – over 90% of businesses say they will transition to passwordless authentication at some point in the future.

Yet, the path to a fully passwordless future isn’t as quick or trouble-free as we might like to think. In the way are issues of user experience, interoperability and inconsistent technical implementation – all of which could thwart the frictionless, passwordless dream passkeys promise.

While passkeys can dramatically improve the security and UX of authenticating users to applications, there’s a lot that still rests on the shoulders of developers.

In this article, we’ll go over what differentiates passkeys from prior passwordless authentication methods, the top developer challenges and pitfalls around implementing passkeys and the top three considerations for dev teams when configuring passkeys for their app.

Behind the Hype – a “Drop-In Replacement” for Passwords

In many ways, the technology behind passkeys is not new. By definition, passkeys are still WebAuthn credentials. They combine public key cryptographic pairs with an additional method of identity verification – a public key is stored on an application’s server, while the private key is stored on a local device belonging to the end user, either a USB key or sometimes simply locked behind a biometric factor.

This combination of public key cryptography with either ownership-based or biometric-based identity verification makes WebAuthn virtually unphishable.

But it also means that historically, WebAuthn has also been device-specific – meaning if a user lost their USB key or simply wanted to access an app or service on a device other than the one with their biometric information on it, they were out of luck.

Passkeys drastically uplevel the usability of WebAuthn technology because they’re usable across devices and operating systems. So even if users set up a passkey for an app or service on their iPhone, they can use that passkey to log into the same app or service from their iPad and SurfacePro. And, passkeys are designed to be easily discoverable – if a user visits a site or opens an app for which they have a passkey already, their device and/or app will prompt them, making it easy to autofill.

All of this blends to make passkeys as universally usable as passwords and as secure and unphishable as WebAuthn, at least in theory.

In practice, there are still hurdles developers face in implementation that can have a big effect on user experience and security.

Developer Implementation Challenges

Three big factors affect what kind of passkey experience trickles down to the end user: The end user’s platform, the developer’s technical configuration and the UI implementation of the passkey.

End user’s platform
One of the key aspects that make passkeys usable across devices is that they’re synced to the cloud. But between a user’s operating system, cloud ecosystem, browser and device, this syncing ability is not guaranteed.

For example, a passkey set up on macOS within Safari will sync to iCloud, but will only remain locally available if set up on Chrome. A passkey set up on an Android within Chrome will sync to Google Password Manager, but unlike more stringently protected biometric storage options (like Keychain), Google Password Manager is not nearly as secure.

Another aspect of your end user’s platform that will impact security is the presence (or absence) of a biometric reader. Part of what makes passkeys so secure is that they combine a what-you-have auth factor (your private key) with a who-you-are (e.g. your fingerprint or face ID). But if you allow your users to use their phone’s PIN instead of a biometric factor, that makes your passkey implementation a much more phishable and vulnerable attack vector.

Technical configuration
While you can’t necessarily control which platform your end users choose, you can make proactive decisions in your passkey implementation that affect security and UX.

1. Authenticator type: In the current state, only passkeys created via platform authenticators will allow syncing to the cloud, while passkeys created via cross-platform authenticators can’t be synced to the cloud.
2. Resident key: Resident keys allow for the storing of metadata with the creation of a passkey. If resident keys are not required, it can prevent passkeys from being discoverable client side.
3. User verification method: If you can’t guarantee that your end users have access to a biometric scanner on their device, you may need to open up approved user verification methods to include things like PINs. But again, that currently means you’re forced to trade wide adaptability for stronger security.

UI implementation
The humble autofill function may seem like a modest enhancement, but for users who have ~ 80 apps downloaded on their phone and may access upwards of 10 apps a day, an autofill feature can make or break their productivity and mood.

In order for passkeys to be discoverable, developers must enable conditional mediation – allowing apps to scan a device for saved credentials, as well as the autofill function – as you can guess, allowing the device to autofill credential fields.

Top Three Considerations

Depending on your users and your application, there is no single right way to implement passkeys. Navigating your own implementation requires three very basic considerations.

1. Know your users
It may sound obvious, but for your passkeys implementation to succeed with users, you need to make sure it’s configured for their use case. Consider your users’ device preferences, such as desktop or mobile, and whether they use Apple, Windows, Yubikeys or other authentication methods to tailor your passkeys implementation accordingly.

These preferences will have a big impact on the exact configuration that makes the most sense for your customers.

2. Know your risk tolerance
You also need to understand the risk tolerance for your use case. While security and user experience are not always necessarily in tension, until passkeys enjoy more universal support across devices and ecosystems, you may need to make some very calculated decisions about where your company feels they’re most vulnerable to attacks and where you might be able to offer a more flexible experience for your users.

3. Closely track the terrain
Depending on when you read this, it’s highly possible that one of the major passkeys providers will have updated their ecosystem/browser compatibility or released a new set of devices with biometrics. These developments have a big impact on how your passkeys implementation will work on the ground, and they’re changing rapidly. In general, that change is a good thing – it’s part of what is helping to accelerate passkeys adoption and the passwordless revolution. But it’s also what makes the management of a passkeys implementation challenging for in-house devs.

Get Started Now

While some of these choices may seem daunting, passkeys’ momentum is undeniable – and its potential completely attainable. The best thing developers can do right now is start working on a plan to enable passkeys-based authentication – ensuring their app is primed for the passwordless revolution.

December 1, 2023
Can Unlocking Joy Unlock Developer Productivity?

Software development has become more complex in the last 10 years with the introduction of the cloud, containerization and microservices – not to mention increased attention to security and governance. All of which falls on developers to manage.

On the surface, this seems like a sensible way to keep engineering organizations lean. But it comes with a price. The increased cognitive load combined with less time for actual coding turns what should be an exciting job into a series of chores.

As CTO of Atlassian, my goal is to build a world-class engineering organization. I want our team of 5,000+ developers to be productive, sure. But more than that, I want them to experience the joy of creation and a sense of pride in their work.

So, my leadership team and I made a strategic bet. We wagered that unlocking developer joy would, in turn, unlock productivity. It’s paying off so far, and I believe it’s an approach that can work for any engineering organization.

Where is the Love?

To be clear, the goal isn’t joy for its own sake. It’s joy in the service of improving productivity across the engineering department. Because it’s not as if developers are inherently lazy, they want to perform at a world-class level. So what’s getting in their way?

Unsurprisingly, our devs knew exactly what was slowing them down: Brittle systems in need of some major TLC, lack of time to fix them and fundamental best practices that had fallen by the wayside. It was papercut after papercut, sapping the energy from even our most enthusiastic engineers.

With that in mind, we looked for ways to remove friction so our devs could stay in their flow state longer. We ultimately arrived at a three-part framework that has proved successful. In concert, we defined baseline metrics for overall developer satisfaction, the time between commit and deploy, pull request cycle time, self-serve documentation and self-serve dependency maintenance. You can’t improve what you don’t measure, after all.

Part One: Provide Awesome Tools

Even before we finalized our baseline metrics, we knew that cycle times for deployments and pull requests were too long. Other issues we identified stemmed from macro-level changes across the industry. Like the fact that increasingly a lot of software is assembled from existing components, we believe this trend will only increase over time.

Most SaaS products, Atlassian’s included, comprise hundreds of microservices, libraries and other components woven together with fresh code. If you need to get up to speed on an unfamiliar microservice, it can take hours to locate the documentation or wait for a colleague several time zones away to come online.

We built Compass to solve this. It removes friction by establishing a self-serve catalog of all software components, including who owns each one, changelogs and health-check metrics. Other work in this area includes introducing new automation in the pull request process, migrating to new test libraries, and external service mocking to enable testing against upstream services within a local dev environment.

We’ve set incremental goals with milestones every few months to maintain a sense of progress and momentum. As of now, we’re tracking toward a 90% reduction in the time it takes for changes in shared services to make their way into individual products.

Part Two: Empower Teams to be the Change They Seek

Our developers were well aware of the issues slowing them down but didn’t feel they had permission to spend time fixing them. So my leadership team, with support from Atlassian’s co-founders, told our development teams to use 10% of their time removing speed bumps.

For example, before our developer joy initiative, less than 12% of the Confluence team’s pull requests reached production within 48 hours. Through a combination of restructuring their repositories, improving test efficiency, and deployment pipeline automation, they bumped that number up to 31% in just one quarter.

Similarly, the Trello team eliminated 24,000 lines of obsolete code and adjusted their branching model to reduce code freezes. Another team increased their deployment frequency by 300% by eliminating manual approvals for low-risk changes.

These are just a few wins we’ve scored by granting teams more latitude and asking them to explicitly set time aside to fix things.

Part Three: Foster an Amazing Engineering Culture

We want Atlassian Engineering to be known for clean code, an ownership mindset when it comes to quality and strong, agile practices.

On the coding side, I thought back to my days of working on the Windows NT operating system. The code was rich with comments and supporting documentation that let me understand it on the very first read. That’s not the case with all of Atlassian’s code, so we’re in the process of modernizing our code base and documentation.

We’re also building a framework for engineering standards. This includes guidance that helps engineers write the right tests at the right time, as well as pulling considerations like security and compliance upstream. We want secure and compliant code from the start so we have fewer rewrites on nearly complete features.

An amazing engineering culture also creates space for developers to learn, experiment and share. To that end, we’ve run hackathons focused on developer productivity and started a monthly internal newsletter showcasing the progress we’ve made. We’re also strengthening our “demo culture” with a weekly showcase where teams present projects they’re working on, exchange ideas and generally catalyze innovation.

Continuous Improvement for the Win

Developer joy and its side effect, developer productivity, is now part of the everyday conversation within Atlassian engineering. It’s also a company-level OKR, complete with funding and a central team that takes on department-wide projects and then rolls them out to the teams.

A year in, our teams are noticeably stronger, moving faster and have more room to test out new tech. (We’re especially excited about our experiments with AI tools like coding assistants and all the opportunities to build on top of our AI platform.) And we can see this in the data. At the start of this initiative, only 50% of our developers reported being satisfied with their work environment. Now, our internal surveys show that number hovers around 70%.

A code base is like a human body; if you take care of it, it’ll take care of you. If you neglect the upkeep, however, eventually, it’s going to break in very painful ways. This isn’t just a project – it’s a lifestyle. There will always be a next step to take. I couldn’t be happier that we’re on the path toward greater developer joy and have come this far in such a short time.

November 27, 2023
Cutting Costs, Boosting Efficiency: The Economic Benefits of Framework-Defined Infrastructure

In a world that’s constantly modernizing, developers are at the forefront of progress, embracing cutting-edge tools that match the pace. Industry-standard practices like infrastructure-as-code (IaC) are getting an update: Framework-defined infrastructure (FdI) is an approach to deploying applications that is quickly gaining popularity among developers, where the deployment environment automatically provisions infrastructure derived from the framework and the applications written in it. For developers, this serverless architecture means more reliability, increased productivity, top-of-the-line security and reduced costs.

To modernize development practices, understanding the role of framework-defined infrastructure in defining and automating infrastructure—and its impact on the development experience in open source frameworks—is crucial.

The Evolution From IaC to FdI

Infrastructure-as-code (IaC) is the industry-standard practice for provisioning infrastructure in a repeatable and reliable way. Framework-defined infrastructure (FdI) is an evolution of IaC, where the deployment environment automatically provisions infrastructure derived from the framework and the applications written in it.

In the early days of servers and the internet, we SSH-ed (or worse) into individual machines, running install scripts or even configuring production software using graphical user interfaces to provision infrastructure. As the web scaled, it became clear that this approach wouldn’t scale with it, and together with the DevOps movement, IaC became the best practice for provisioning infrastructure. The code in IaC represents a version-controlled description of the desired state of the infrastructure—which, when executed, will create the described system state. However, as the web continues to scale, developers must apply new processes and architectures to increase the efficiency of their workflows.

Enter framework-defined infrastructure.

Framework-defined infrastructure abstracts over cloud primitives such as servers, message queues and serverless functions, making them mere implementation details of the frameworks’ concepts. Frameworks use well-established patterns to provide structure and abstraction to applications, making them easier to write and understand by managing the high-level application flow while the developer writes code within the hooks provided by it.

Framework-defined infrastructure takes advantage of both this inversion of control and the predictable structure of framework-based applications like Next.js to automatically map framework concepts onto the appropriate infrastructure without the need for explicit declaration or configuration of the infrastructure.

Optimization for Serverless Environments

Since framework-defined infrastructure lets the framework itself define the production behavior, local development can just use the framework’s own tooling, while production infrastructure is automatically configured to be a scaled and optimized representation of the same underlying behavior.

IaC uses machine-readable files, which developers can version much like software, to provision infrastructure such as physical servers, virtual machines and higher-level services like databases or applications. Serverless architecture—which, despite its name, still uses servers—eliminates the need for developers to manage specific physical or virtual servers.

Serverless products still require developers to define and deploy their respective serverless primitives, much like more traditional infrastructure. For example, in the archetype of serverless products, AWS Lambda, developers need to create a lambda function and deploy code to it.

While serverless architecture greatly simplifies managing production infrastructure, the systems that run serverless code are often complex and proprietary, which can cause problems with local development. In a worst-case scenario, local development isn’t possible, and developers must test local changes by making comparatively slow deploys to the production infrastructure. In a best-case scenario, developers must create a local simulation of the complex serverless stack, which must stay up-to-date with the production environment. Framework-defined infrastructure completely eliminates this problem, as it is capable of automating the process for users.

Framework-Defined Infrastructure and Immutable Deployments

These days, application code is developed almost exclusively within version control systems such as Git. IaC maintains infrastructure definition in either the same or a sibling version control system. However, production infrastructure itself can only represent limited points in time of the infrastructure’s version history. This is fundamentally incompatible with framework-defined infrastructure, which expects that production infrastructure directly maps to the framework code at the same commit hash.

Immutable deployments solve this impedance mismatch between an application’s and the infrastructure’s version history. Instead of deploying onto a limited number of infrastructures, immutable deploys create a completely new infrastructure for every single deployment that is ever made. For developers, this means lower IT complexity and failures, improved security, and easier troubleshooting, given there are fewer chances for unpredictable behaviors or unintended consequences of code changes.

Naturally, immutable deployments are impossible in a world where infrastructure is mapped to finite physical resources. However, in a serverless world, where unused infrastructure can scale to zero, immutable deployments become possible to perform, as unused deployments do not take up physical compute resources beyond the baseline storage needed for their contents.

Conclusion

It goes without saying that framework-defined infrastructures rely on IaC as the ultimate infrastructure interface and, hence, could not work without the amazing work of its community. In order to modernize, it’s imperative for developers to leave behind infrastructure constraints and embrace a world where scaling applications becomes effortless, enabling them to optimize efficiency without sacrificing performance. For developers growing frustrated with scaling issues or the burdensome process of their development process, widespread adoption of framework-defined infrastructure is key to improving the developer experience.

November 15, 2023
A Practical Guide to Mitigating DevOps Backlog

Every company aspires to get the first-mover advantage in its respective industry. This strategy allows companies to establish a robust brand presence and offer strong product offerings in the market. However, at times, this may also lead early-stage startups to prioritize pushing product features to market without adequate consideration toward stabilizing and maintaining the product. The above-mentioned approach may help win business and keep customers satisfied; achieving excellence in DevOps still remains an elusive goal. From operational issues to the lack of focus on streamlining DevOps, several factors add up to the already existing pile of DevOps backlog.

According to the Puppet DevOps report 2023, nearly 80% of organizations remain in the middle of their DevOps journey, experiencing varying levels of success within the team level but not across the entire organization. And, one of the areas that could hinder an organization’s success is the accumulating pile of DevOps backlog.

What is DevOps Backlog?

In typical software development teams, the primary focus is often on crafting functional and groundbreaking solutions, which is understandable given the constant drive to meet strict deadlines and deliver exceptional products. However, this relentless cycle of prioritizing outputs can inadvertently relegate the development process to a lower priority, resulting in the accumulation of tasks and issues contributing to the DevOps backlog.

DevOps Backlog consists of user stories, bug fixes, technical tasks, or any other work required in supporting and sustaining the development, deployment and maintenance of a product. It is dynamic and changes with time as and when new tickets get added to the list.

Key Factors Fuelling DevOps Backlog

Managing a substantial DevOps backlog can be one of the most complex challenges for companies to overcome. Within the CI/CD pipeline and the collaboration of multiple teams, intricate system architectures and more, several potential drivers contribute to the growth of the DevOps backlog. Let’s explore some of them:

Relying on a Small DevOps Team: In many cases, DevOps teams consist of a limited number of specialists who act as the lynchpin, holding various processes together. Larger development teams often rely on these smaller DevOps teams, resulting in dependencies that lead to blocked pipelines and delayed handovers, further adding to the DevOps backlog.

Architecture Changes: As development progresses and new services are introduced, architectures naturally evolve and change. This constant evolution necessitates new tooling and infrastructure requirements. Adapting to these changes and aligning new tools and frameworks with the evolving architecture contribute to the pile of the DevOps backlog.

Adapting to Changing Business Requirements: Business requirements are dynamic and evolve over time, adding complexity to the DevOps backlog. For instance, if your organization operates as a software-as-a-service (SaaS) provider or in the healthcare industry, you may need to establish new environments tailored to specific countries, regions, or regulatory frameworks. Managing these new environments and ensuring compliance with relevant regulations adds to the workload of the DevOps team and adds to the DevOps backlog stockpile.

Ticket Overflow: In many scenarios, developers do not have direct access to DevOps toolchains, resulting in an abundance of developer tickets that need to be processed by the DevOps team. This flood of tickets significantly reduces the bandwidth and efficiency of the DevOps team, impeding their progress in addressing the backlog.

Mitigating DevOps Backlog: Prioritizing Essential Strategies

While collaborating with companies to establish DevOps standardization, we initially assumed that the DevOps backlog challenge was limited to a select few. However, we were surprised to discover that even well-established companies in the later stages of product development struggle with significant DevOps backlogs without strategic interventions. Our conversations with over 200 organizations convinced us that the DevOps backlog is a prevalent issue faced by most companies today.

A Lack of Focus on Proactive Approach

The symbiotic relationship between business growth and technological advancements is undeniable. As time progresses, the architecture inevitably becomes more intricate, resulting in a growing number of tasks and challenges within the DevOps backlog. The complexities surrounding DevOps resonate with numerous companies, yet the proactive approach to addressing them remains an issue.

At our organization, we firmly believe that discussions revolving around DevOps stories are vital for organizations aiming to tackle this critical issue head-on. Now, let’s delve into the top 10 stories that software development teams can incorporate into their backlog to strike a balance between prioritizing software development and implementing essential process improvements.

1. Automating Provisioning and Configuration of Resources and Infrastructure
Proper provisioning and configuration of resources and infrastructure are vital for software development and deployment teams. By automating these processes and leveraging the appropriate toolchains and metrics, teams can streamline resource management, fostering consistent and efficient deployment practices. This, in turn, leads to enhanced productivity and improved overall development efficiency.

2. Application Life Cycle Management
Application life cycle management encompasses the comprehensive management of an application throughout its entire life cycle, from development to deployment and beyond. Teams that engage in discussions surrounding these stories take the necessary steps to streamline the entire life cycle. By leveraging toolchains and implementing proficient workflows, these teams achieve heightened productivity and maintain consistency across the application’s lifespan.

3. Release Management and Strategies
Stories related to release management and strategies go beyond mere release scheduling. They encompass crucial aspects such as zero downtime deployments and the implementation of effective rollback strategies. By prioritizing these stories, development teams can ensure smooth and seamless deployments, minimizing disruptions for end-users and optimizing the user experience.

4. Observability
Observability is the key to implementing effective monitoring practices for applications. This involves setting up alerts, capturing relevant metrics and configuring dashboards to track application performance and resource utilization. Prioritizing observability empowers teams to proactively identify and resolve any issues within the DevOps pipeline, ensuring a stable and reliable environment for continuous improvement.

5. Database Management
Database management entails activities such as upgrading and migrating databases, implementing scheduled backups and defining restoration policies. A robust approach to database management ensures the stability and reliability of the data infrastructure, mitigating the risks of data loss or downtime. By prioritizing this story, teams can safeguard their valuable data assets and maintain operational continuity.

6. Access and Permissions
Secure access and permissions are essential for developers across different environments, including testing, staging and production. This story emphasizes the importance of maintaining a transparent audit trail, identifying and rectifying permission leaks and ensuring compliance with security standards. Prioritizing access and permissions not only promotes a secure development environment but also minimizes the risk of data breaches or unauthorized access.

7. Environment Creation and Management
Establishing and managing environments is a complex and time-consuming process that requires collaboration among various stakeholders. From development to quality assurance (QA), pre-production and production environments, meticulous configuration and provisioning are paramount. By addressing this crucial need, teams can ensure well-prepared environments, minimizing discrepancies that may arise during the development and testing stages.

8. Security and Compliance
Security and compliance are fundamental elements that should be considered when designing and implementing an architecture. Adhering to the standards and regulations defined by the geographical countries of deployment is crucial. Neglecting this aspect could result in substantial fines, vulnerabilities and the need for extensive damage control in the future, wasting valuable resources. Therefore, prioritizing security and compliance is imperative for long-term success.

9. Cloud Cost Visibility and Optimization
The dynamic nature of cloud computing necessitates efficient monitoring and optimization of costs, striking a delicate balance between frugality and system performance. Teams must possess comprehensive visibility into cloud cost usage to identify areas of potential savings. By scrutinizing resource allocation, assessing utilization patterns and implementing cost management strategies, organizations can minimize expenditure without compromising the functionality and stability of their applications.

10. Exploring New Tools and Frameworks
It is imperative for organizations to continually explore new tools and frameworks that help elevate software development practices. By implementing zero-trust networks and network segmentation, teams can fortify their security measures, bolster network resilience, and proactively mitigate potential risks. By remaining at the forefront of technological advancements, teams harness the power of these transformative tools and frameworks to optimize overall efficiency and propel innovation to new heights.

Intervene Now to Tackle DevOps Backlog

Prioritizing product features over process can lead to complex issues in DevOps backlog. Solving this problem requires a major shift in mindset and a proactive approach toward mitigating DevOps backlog. Whether your DevOps backlog is in the initial stage or has reached a later stage where it is getting more complex, the time to intervene is now.

November 6, 2023
How to Get Developer Productivity Engineering Right

Executives want a clear measurement of developer productivity, but determining it is proving elusive. Because how do you even define software development productivity? Is it the number of points you completed during a sprint? Lines of code or bugs fixed? Features correlated with tangible business outcomes? Or, is it the satisfaction you feel after a day’s job well done? Or is productivity shaped by the social cues you get from your colleagues?

When Brian Houck, principal productivity engineer, Microsoft, asked this question to the thousands of internal developers at Microsoft, he was surprised to see hundreds of different answers across all the above areas. “Developer productivity is many things and means different things to different people,” said Houck.

I recently attended DPE Forum: NYC, which brought together leaders in the burgeoning field of developer productivity engineering (DPE) to share their experiences implementing DPE in practice. Hosted by Gradle on October 3 at the Nasdaq MarketSite building, the event was an eye-opener into the science behind DPE, data-backed internal studies on developer productivity, and what engineering managers are actively doing to improve efficiencies.

Below, I’ll highlight some key takeaways from talks at the DPE Forum to help you get an edge on this emerging practice. We’ll end with some actionable developer productivity tips that you can apply to your own engineering culture.

Reduce Feedback Cycles to Reduce Cognitive Fatigue

According to Hans Dockter, CEO and founder, Gradle Inc., developers see a huge latent potential in optimizing their toolchain. But, although engineering leadership is becoming more open to new DPE initiatives, they tend not to feel as strongly about its potential. Leaders may not see anything wrong with waiting for a ten-minute build, telling developers to “just check your email while you wait.”

Yet, studies have found that the productivity of multitasking teams is far less than that of teams that focus on singular tasks. Furthermore, cognitive control tasks, in which the brain must build new neural pathways, contribute to added mental fatigue. The pervasive ‘multitasking myth’ leads to a superficial perspective that is a blocker to improving the toolchain processes, said Dockter. “When your muscle is exhausted, it’s a biological effect.”

So, how can we reduce cognitive fatigue? Well, Dockter attributes cognitive fatigue and burnout in part to the lack of quick feedback while testing new builds. Code verification failures, flaky tests and failed CI/CD builds can really yank developers out of a ‘flow state.’ And he’s found that when the feedback cycle is longer than ten minutes, you tend to get more task-switching, accelerating cognitive fatigue and decreasing productivity.

The benefit of investing in DPE, he said, is reducing this feedback cycle, thus reducing context switching that contributes to cognitive dissonance. “You cannot have a great developer experience without a great toolchain experience. And that’s what DPE is about.”

Case Study: Decreasing Cycle Time at Netflix

Engineering leaders are actively looking for ways to keep developers in the “inner loop” with fewer interruptions. Netflix, for example, has been investing in ways to improve developer experience around their toolchain, like instigating automated retries for flaky tests. Aubrey Chipman, senior software engineer, Netflix, shared how Netflix Engineering is actively configuring and optimizing their testing processes to reduce this cycle time.

As part of these endeavors, many Netflix projects now use Testcontainers to optimize testing. They also use Gradle’s Develocity for predictive test selection (PTS), which Chipman estimated has saved roughly 30 thousand potential hour savings in a year.

Netflix is also toying with remote test execution (RTE) as a beta offering, which distributes tests across remote agents to execute them faster. However, Chipman acknowledged that parallel executions come with potential limitations, such as network security issues and debugging for different environments.

Build a Systematic Approach to Developer Velocity

Although all teams are special snowflakes, there are definitely common requirements they all share. This is why the idea of an internal developer platform (IDP) has seen greater interest lately. IDP architectures deliver common ‘paved roads’ to internal developers with guardrails to remove friction within the software development life cycle (SDLC).

Amado Gramajo, VP, infrastructure and DevOps engineering, Nasdaq, defined DPE as enhancing developer productivity and happiness through accelerated technologies. And to him, the SDLC really has focused on improving the Ops side in recent years. Now, there is a big opportunity to focus on improving the build and testing aspects of this toolchain.

To distribute common features, Nasdaq adopts a systematic approach to developer velocity, as he called it. They haven’t created a centralized team per se but have developed a shared service available to all developers to help them improve velocity. This global service cuts across otherwise siloed teams, bringing them shared requirements, like resiliency and compliance features. As areas like Kubernetes, SRE and containerization become more normalized, said Gramajo, we need to build the operational controls so things can be automated.

Case Study: Tracking Toolchain Data at GitLab

Some are taking the idea of a systemizing developer velocity quite literally. For instance, Lee Faus, global field CTO, GitLab, described the concept of operating a ‘software factory.’ How can we optimize the supply chain to figure out how to produce artifacts that customers are happy with every single time, just like Oreo cookies?

Well, Faus identified a core issue in webhooks, which he referred to as “the dumpster fire of our toolchain,” he said. Every tool emits different events, which are produced by many actions within the toolchain. However, if this data isn’t properly triggered or received correctly, you could easily have data corruption, causing issues in the testing process.

Therefore, Faus recommended properly handling event data with solutions that enable bi-directionality and avoid creating data silos. Ideally, collecting data related to the software development process should be traversable to help developers pinpoint where problems emerge from. And this root cause analysis should be tied to actionable outcomes for remediation.

Base DPE Descisions on the Data

Although defining productivity is challenging, we have data to back up certain actions leaders can take to increase developers’ perceived productivity and satisfaction. After surveying thousands of internal developers at Microsoft, Houck was able to make some data-backed recommendations.

Formerly Set Aside ‘Focus Time’

The first finding isn’t surprising. Developers like to code. They don’t like things that distract them. Houck’s research found that the amount of time spent coding was positively correlated to developer satisfaction. Engineers who formerly blocked off uninterrupted time to code (especially in the morning) are far more likely to say they are productive. This perceived productivity remains, regardless of whether focus time is chosen or mandated.

Practice Meeting Hygiene

One way to free developers up for more concentrated work is to reduce their time in low-quality meetings. These could be recurring meetings that have outlived their usefulness or ones where the information is not relevant in the first place. Yet, interestingly, not all meetings are bad. For example, Houck’s research shows developers are 2.5x more satisfied with one-on-one syncs with their direct manager.

Allow Flexible Work Arrangements

Houck’s research found that happiness and productivity linearly decline as developers are asked to go into the office more often. The findings are clear—remote workers are more likely to feel more productive than fully on-site workers. Furthermore, the developers who don’t have agency in where they work feel 11% less productive. While there are certainly benefits to in-person brainstorming and team-building, leaders shouldn’t force engineers back into the office for an arbitrary number of days.

Final Thoughts

Measuring developer productivity is a tricky art. Therefore, Houck recommends choosing a few metrics, such as developer satisfaction, the amount of dedicated focus time developers have and the degree of friction within their workflows.

Similarly, Dockter recommended measuring the obstacles and hidden costs in the developer toolchain—obstacles like slow build and testing cycles—that can be readily removed to logically enhance productivity. “The toolchain gives you indications that certain teams are not as mature as others,” he said. Implementing DPE is steady progress, not firefighting, so you’ll probably want to sneak these changes in slowly, he added.

Fitter, happier, more productive. Developer productivity engineering is an emerging practice with a lot of science and opinions surrounding it. But there’s also the human factor to consider. A solid engineering culture will require meeting people halfway and giving them purpose and incentives to retain their interest.

Finally, anyone’s bound to get burned out sometimes with work. At least by minimizing the unnecessary toil in the toolchain, we can encourage a more satisfied developer experience that keeps up high productivity—however you want to define it.

October 10, 2023
Generative AI’s Impact on Developers
There is a growing belief in the developer community that future software development will be performed by machines rather than humans by 2040. Software development will undergo a radical change with the combination of machine learning, artificial intelligence, natural language processing and code generation that draws from large language models (LLMs). Most organizations believe that there will be a 30-40% improvement in overall developer productivity with AI. While these arguments have some merit, I do not believe developers will be fully replaced. Instead, I believe generative AI can augment developers to support faster development and higher-quality code.

I’ll address the impact of generative AI on the development community under three pillars:
- Automation and productivity
- Quality engineering and compliance
- Ways of working
Automation and Productivity
- There will be a focus on increased automation all the way from business planning to operations of applications.
- LLMs can help provide better alignment of user stories to business requirements. In fact, one of the best use cases for generative AI during planning phases is to auto-generate user stories from business requirements documents.
- Since ambiguity of requirements or guesswork is taken out of the equation, one can expect a clearer “definition of done” through the auto-creation of acceptance criteria.
- In a typical development cycle, 15%-20% of coding defects are attributed to improperly defined requirements. Generative AI augmentation can result in significant reduction of those defects.
- Generative AI augmentation can help developers with better planning and estimation of work. Rather than relying on personal experience or home-grown estimation models, LLMs can better predict the complexity of work and developers and continually learn and adapt through multiple development sprints.
- AI-augmented code creation can allow developers to focus on solving complex business problems and creative thinking rather than worrying about repetitive code generation. Over the last decade or so, the perception of software development as a creative pursuit has been a dying phenomenon. With AI, I think that more and more younger developers will be attracted to the field. AI will put the “fun” back in coding.
- AI-assisted DevOps and continuous integration will further accelerate deployments of code so developers can focus more on solving complex business problems. Deployment failures due to human errors can be drastically reduced.
- Elaborating on the above, newer and less experienced developers can also generate higher-quality code with AI-augmentation, leading to better overall consistency of code in large programs.
- Overall, from a development standpoint, I think AI augmentation will free up 30% of developers’ time to work on enhancing user experience and other value-added tasks.
Quality Engineering and Compliance
- In a hybrid cloud world, solutions will become more distributed than ever, making system architecture more complex.
- LLMs can assist in regulating design documents and architecture work products to conform to industry/corporate standards and guidelines. In essence, LLMs can act as virtual Architecture Review Boards. In a typical development life cycle, architecture/design reviews and approvals make up 5%-8% of work and augmenting the process with generative AI capabilities can cut that time in half.
- Ssecurity compliance for cloud-based solutions is imperative. LLMs can assist in ensuring such compliance very early on in the development life cycle, leading to more predictable deployments and timely program delivery.
- Generative AI-augmented test case creation can optimize the number of test cases needed to support the development while increasing the overall code coverage for quality.
- For greenfield development, there can be a 20%-40% increase in overall code quality through automatic bug-fixing embedded within a DevOps pipeline. Developers can focus on bug avoidance rather than bug fixes.
- AI-augmented test data generation can increase testing cycles by 25%. Proper test data availability has been a big pain point for quality engineers for decades.
Ways of Working
- Developers will have to shift their focus to understand how to use the right AI models and prompts to generate documents, code, test cases etc. rapidly. This is a change from writing everything from scratch. Picking the right model for the right use case is very important from an overall efficacy standpoint while also remaining cognizant of the trustworthiness, security and data lineage of the models. This is why I don’t think developers can simply be fully replaced (at least not in the near future).
- Generative AI is not magic. It does what it is trained to do based on the examples it is provided and how well it is prompted. Developers will need to quickly learn and adapt to this new paradigm.
- This requires different sets of skills and training for developers. It is also incumbent on management to ensure developer enablement happens so they can succeed in this new world. Simply having an AI technology strategy without a developer enablement strategy means a failed overall strategy. The outcomes will not be fruitful.
AI-enabled development is here to stay, despite the nervousness in the developer community. Of course, there are some good reasons to be nervous. Generative AI, unlike many other revolutionary technologies that have emerged in the recent past, doesn’t just enable work but creates “things.” And there is a school of thought that believes this creation will displace developers. It won’t. Generative AI-augmented development will provide developers with a pathway to higher creative thinking, which really is one of the fundamental aspects of software development.

My message to the development community: Don’t fear generative AI; embrace, learn about and from and enjoy creating with generative AI.
September 27, 2023
Fortifying the Castle: A Quest to Secure the SDLC

Every business is a software business today. But as the pressure to churn out new applications and features grows, so do the chances of developers making mistakes. Tackling these challenges doesn’t just require more diligent developers, it requires continuous education across the software development life cycle (SDLC).

To borrow a metaphor from Arthurian legend, it’s a never-ending battle against hidden risks and formidable adversaries. It will require security champions to share their wisdom and bring order to the kingdom.

A Kingdom Under Siege

These are dark times for those fighting the good fight. The threat landscape is a wild and unruly place where risk is everywhere, and adversaries often have the upper hand. They have the advantage of surprise and are masters at hiding in the shadows. But the threat is real. One vendor blocked over 146 billion threats last year alone.

Many of these attacks take advantage of vulnerabilities in code. It’s a problem made more acute by the widespread use of open source components by today’s developer teams. One estimate suggested that last year alone, developers made 3.1 trillion requests for these components from the top four open source ecosystems. Yet many of these components contain vulnerabilities. According to the Linux Foundation, the average application development project features 49 vulnerabilities across 80 direct dependencies. Worse are the indirect dependencies that are far harder to track and, by some estimates, account for six in every seven project vulnerabilities.

That makes software supply chain attacks and breaches far more likely, especially as threat actors are actively placing buggy components in upstream libraries with the hope they’ll be downloaded en masse. It’s also getting more likely because developers are coming under increasing pressure to deliver. It’s claimed that over half of developers handle a hundred times more code than they did a decade ago. And most are under pressure to write code faster. This increases the chance of mistakes happening, which in turn can cause significant financial and reputational damage.

Fighting Back

The answer to these mounting challenges has traditionally been to focus on “shifting left” or moving testing and scanning earlier in the SDLC. To ensure products are designed with security from the outset, it’s essential to follow “secure-by-design” principles. However, this is only half the picture. Scanning for vulnerabilities is certainly important, but even better is to ensure teams are building more robust code from the outset. Prevention is always cheaper and more effective than cure.

This is where continuous secure coding education comes in. Continuous because technology and market demands are always changing. In this dynamic world full of risk, a one-and-done approach simply doesn’t cut it. Further, courses should be extended beyond the realm of the developer to every member of the SDLC team: From project management and UX specialists to QA, product management and beyond. All must share a common goal with a common responsibility to produce more secure code. Some will be security champions who share best practices with other stakeholders. But everyone must be pulling in the same direction.

Time to Fortify the Castle

So once the kingdom has assembled its diligent developers and security champions, what’s next? With the knowledge and skills imparted through continuous training, plus additional automated checks, real progress can be made to enhance security and resilience.

If you’re familiar with the OWASP Top 10, you’ll recognize concerns such as server-side request forgery, misconfiguration, using vulnerable components and shortcomings in security logging, cryptography and software integrity. A stronger focus on foundational security practices like the principle of least privilege, separation of concerns and layered defense can mitigate these risks. Among the most prevalent threats are injection attacks, which include SQL injection and cross-site scripting. However, by using tools and having developers well-versed in strategies like input validation, parameterized queries, data cleansing and secure LDAP queries, these threats can be effectively addressed.

Above all, it’s important to remember that everyone has a part to play in fortifying the castle, in protecting the kingdom from a mounting and formidable agglomeration of threats. That means, as a baseline, that everyone should be getting some form of continuous secure coding training. There’s no time to waste.

September 26, 2023
CloudBees CEO: State of Software Development is a Disaster

CloudBees CEO Anuj Kapur told attendees at a DevOps World event today that with developers spending only 30% of their time writing code the current state of software development in enterprise IT organizations is a disaster.

After more than 14 years of effort, the promise of DevOps—in terms of being able to accelerate the rate at which applications are being deployed—remains largely academic, said Kapur. In fact, the effort to shift more responsibility for application security further left toward developers has only increased the amount of cognitive load and reduced the amount of time available to write code, he noted.

However, with the rise of generative artificial intelligence (AI), an inflection point that will dramatically increase the velocity at which applications are being built and deployed has arrived, said Kapur. The challenge will be achieving that goal without increasing the cognitive load on developers. That cognitive overload results in 70% of developers’ time not being productive within organizations that often hire thousands of developers, he noted.

Despite all the DevOps issues that need to be addressed, AI advances promise improvement. The overall DevOps market is still relatively young, given the current level of adoption, said Kapur. “We continue to believe the market is early,” he said.

Today, CloudBees took the wraps off the first major update to the open source Jenkins continuous integration/continuous delivery (CI/CD) platform to have been made in the past several years. At the same time, the company also unveiled a DevSecOps platform based on Kubernetes that is optimized for building and deploying cloud-native applications based on portable Tekton pipelines. That latter platform provides the foundation through which CloudBees will, in the months ahead, apply generative AI to software engineering to, for example, create unit tests on the fly and automate rollbacks.

In addition, DevSecOps capabilities will be extended all the way out to the integrated development environments (IDE) to reduce the cognitive load of developers.

The overall goal is to reduce the number of manual processes that create bottlenecks that make it challenging to manage DevOps at scale.

Criticism of the level of developer productivity enabled by DevOps compared to other development approaches needs to be tempered, said Tapabrata Pal, vice president of architecture for Fidelity Investments, because it still represents a significant advance. There is still clearly too much toil, but the issues that impede the pace at which developers can effectively write code tend to be more cultural than technical, he added.

Organizations are not inclined to automatically trust the code created by developers, so consequently, there is still a lot of friction in the DevOps process, noted Pal.

In theory, advances in AI should reduce that friction, but it’s still early days in terms of the large language models (LLMs) that drive generative AI platforms and their ability to create reliable code, he added. That should improve as LLMs are specifically trained using high-quality code, but in the meantime, the pace at which substandard code might be generated could overwhelm DevOps processes until AI is applied there as well, said Pal.

Thomas Haver, master software engineer for M&T Bank, added that while assisted AI technologies will have a major impact, it’s not reasonable to expect large organizations to absorb them overnight. Patience will be required to ensure advances are made in ways that are both secure and sustainable, he added. In some cases, organizations may opt to build their own LLMs to achieve that goal, noted Haver. “You should not expect to change on a dime,” he said. “It will take time to see the fruits of our labor.”

While many DevOps challenges need to be resolved, the benefits continue to outweigh the cost and effort required to succeed. The hope is that, with the help of AI, the return on those investments will continue to accrue.

September 14, 2023
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.

September 11, 2023
Low-Code and AI: Friends or Foes?

The lines are becoming blurred between low-code and new artificial intelligence (AI). Historically, low-code/no-code platforms have introduced software development automation through graphical user interfaces, enabling professional and citizen developers alike to quickly build workflows and generate applications. But the rise of large language models (LLMs) represents an existential threat to the status quo of low-code development.

So, are generative AI and low-code friends or foes? Since new generative AI can produce complex code in milliseconds given natural language prompts, the barrier to software development has never been lower. On the other hand, enterprises already have ingrained low-code practices and operations, which may stick around for a while. With that in mind, there are plenty of ways AI and low-code can coexist.

Below, we’ll consider if AI and low-code are diametrically opposed tools or complementary forces. We’ll see how AI and low-code are merging and consider the benefits of using them in tandem.

Unleashing the Power of AI

LLMs, like OpenAI’s GPT-3.5 and GPT-4, can deliver impressive software generation capabilities, such as creating code snippets and even complete programs given natural language prompts. Because of these remarkable capabilities, it makes sense that low-code platforms should be a bit wary of AI.

Artificial intelligence can actually deliver on some of the original promises of low-code, like software democratization, enhanced agility and filling the widening skills gap. “ChatGPT could allow users to make more significant changes to applications, potentially enabling organizations to achieve far more than with low-code and in half the time,” wrote Romy Hughes on devopsy.kinsta.cloud.

There are also plenty of ways LLMs could accelerate the DevOps side of the cloud-native equation. In addition to code generation, AI could help generate configuration manifests, run code tests and perform cybersecurity analysis. While AI can’t fully replace the nuance of human oversight, it can indeed automate more and more elements of the software development life cycle.

Congruence Between Low-Code and AI

Although it appears likely that AI will replace low-code, there are actually many opportunities for symbiosis between the two concepts. Rather than eradicate low-code platforms entirely, LLMs will likely become more embedded within them. We’ve already seen this occur as low-code providers like Mendix and OutSystems integrated ChatGPT connectors. Microsoft has also embedded ChatGPT into its Power Platform as well as integrated GPT-driven Copilots into various developer environments.

“Low-code and AI on their own are powerful tools to increase enterprise efficiency and productivity,” said Dinesh Varadharajan, the chief product officer at Kissflow. “But there is potential for the combination of both to unlock game-changing automation for almost every industry. The power comes from the congruence between low-code/no-code and AI.”

There is also the opportunity to train bespoke LLMs on the inner workings of specific software development platforms, which could generate fully-built templates upon natural language prompts. This would make the LLM more custom-built and relevant to the platform at hand and ease development fluidity. In addition to integrating existing LLMs, another potential synergy is that low-code solutions could help automate the training of new custom AI models.

Tips to Keep In Mind

As with any technology solution, the choices should be driven by concrete business outcomes. Start by defining the business objectives and let that determine the technological solutions to arrive at the outcomes you desire. In the context of low-code and AI, this might equate to deciding between which models to support.

Next, enterprises must avoid risk when using low-code platforms. And on the AI side of the coin, platforms will have to navigate the data privacy and legal complications of using public LLMs. Like any new technology, AI and low-code will require governance, said Varadharajan. “Organizations should step in to standardize the tools, processes and DevOps cycles. Only certain AI-powered tools should be approved for development where there are agreeable security, privacy and IP protection agreements in place.”

He also explained that a focus on change management would be paramount in reaping the benefits of both strategies. “I suspect that the greatest barrier to adoption and implementation will be change management,” he said. “Enterprise users are accustomed to certain ways of working and can be resistant to change, making them unlikely to embrace AI-powered low-code. Leaders should anticipate this and incorporate change management into their AI/low-code adoption strategy.”

Closing The Semantic Gap

Low-code came on the scene to help citizen developers create applications without requiring advanced technical experience. Yet, low-code still requires knowledge of the development platform as well as specific programming terminologies and formulas. But now, since generative AI behaves in response to natural language, it has the potential to instantly bypass this barrier.

“Generative AI closes this semantic gap,” said Varadharajan. “Generative AI serves as a translator, and users no longer have to understand exactly how the system works.”

As more AI pair programmers come onto the market, expectations are rising within all areas of software development, including low-code platforms, to integrate these advanced models. If leaders can navigate the technical change effectively, the outcomes will likely significantly increase agility and output.

“Ultimately, all developers will end up saving time delegating repetitive tasks to these AI-powered pair programmers,” said Varadharajan.

August 17, 2023