Why a Quality Developer Experience Matters to Your Business

A lot of talk has surfaced lately about work culture in light of the Great Resignation. Attrition has been a serious problem, particularly in the technology sector since 2022. Business owners are struggling to attract talent, and are grasping at straws to attract software engineering talent. It seems gone are the days where a ping-pong table and cold-brew coffee taps in the office drew the industry's best employees.

Since software engineers likely represent one of the biggest expenses for your business, it's essential to focus on improving the developer experience with the goal of improving employee retention and increasing your ROI.

What effect does DevEx have on the Bottom Line?

Quality Developer Experience is a virtuous cycle. Engineers who like where they work stay; they invite other talented engineers to come work with them; they preserve institutional knowledge; they write better code; they are passionate about delivering a quality product to their users.

Many things that materially affect developer experience are cornerstones of a software company's technical evaluation. Solid testing practices, automated release pipelines, and visibility tooling are essential for an effective handoff during the transition of ownership of a company, and buyers like to see these things during due diligence.

Today I'd like to take a look at the three pillars of developer experience that we believe are most important to the success of a software company: Continuous Integration and Delivery (CI/CD), Automated Testing, and Logging, Monitoring, and Tracing (LMT).

Continuous Integration and Delivery (CI/CD)

What is it?

Continuous Integration - a software development practice that automatically merges code changes into a shared repository which helps teams make frequent, reliable code changes.

Continuous Delivery - a software development practice that automates the process of releasing code changes to production.

These two components of a the software development process often go hand-in-hand, and can compound into areas such as automated testing, packaging and versioning, etc.

Why is it Important?

In the fast-paced world of software development, teams face the constant challenge of delivering high-quality products while maintaining agility and responsiveness. The responsibility of releasing code can quickly become more than even the most competent engineers can handle. To achieve reliable, zero-downtime releases, implementing a robust, easy to use, and easy to understand CI/CD (Continuous Integration/Continuous Delivery) pipeline is essential.

Quality CI/CD Leads to:

• Accelerated Innovation and Time to Market
• Enhanced Code Quality and Stability
• Improved Developer Productivity and Collaboration
• Documentation and Test Enforcement
• Reduced deployment risks and downtime

Problems of companies that lack CI/CD

CI/CD often gets misplaced as low-priority work, which is unfortunate because the long-term benefits of robust CI/CD pipelines far outweigh the initial investment. CI/CD can provide your teams a force multiplying effect, freeing up precious engineering hours that are otherwise spent orchestrating, retracting, and re-orchestrating tricky and error prone deployments.

Companies who haven't yet prioritized CI/CD often:

• Spend almost as much time releasing code as they do writing it
• Have longer release cycles, with larger batches of code released at a time
• Have frustrated, burnt out engineers
• Experience more bugs in production
• Sometimes lose the ability to release entirely due to employee turnover
• Have more "fires" that damage their reputation with customers

The target state for every software company should be fully automated, zero-downtime deployments. Engineers should be writing feature code, pushing it upstream, and forgetting about it as it goes through a series of validations to determine its customer readiness. Without this kind of system in place, it becomes increasingly difficult to sell your business, as iterating on the existing product requires retaining staff and institutional knowledge during the transition. Automation of code deployment is an essential part of any successful software company. If you're looking for a place to start, checkout our guidelines for MVP CI-CD |a minimal viable CI/CD pipeline.

How does this Affect Developer Experience?

Software engineers want to be engineering software. Building effective CI/CD tooling around your product code allows engineering teams to utilize their time doing just that, rather than performing ad-hoc, error prone, code releases. Having a great CI/CD pipeline essentially augments the engineering team by adding a completely reliable, 24/7 team of core staff members whose exclusive job is shepherding application code through validations to users, and that augmentation team is virtually free. Offload the release process is an essential building block of quality developer experience.

Automated Testing | Unit, Integration & Regression

What is it?

Tests act as the user manual for your engineering team. They're the tool that keeps quality code running well and prevents faulty code from making it to a user. Done well, they can make development orders of magnitude faster, and can vastly improve the experience of working with a particular code base.

When we talk about software testing, we're talking about code that's used to do one or many of the following:

• Document the application logic at a point in time
• Give software engineers access and visibility into a small, digestible piece of the larger application
• Protect against unintended side effects (or bugs) that may pop up during the development process

Different types of tests have their own specific use cases, and should be introduced at different parts of the development process. At DRYCodeWorks, we've distilled testing down into the following designations:

Are there more types? Sure. Do people draw the lines in different places? Absolutely. The point is, for a non-trivial application to be serviceable by more than one software engineer during the life of the application, a minimally viable testing threshold should be met in each of these categories to reduce the total cost of ownership of the application.

Why is it Important?

Good tests give engineers the ability to fearlessly iterate. When integrated into the CI/CD pipeline, tests become a powerful barrage of checks along the release pipeline that prevent faults from getting to production.

Quality testing allows engineers to:

• [Move fast, and break things]
• Make sense of unfamiliar code faster
• Fetch a better business valuation
• Scale their engineering teams efficiently

The need for testing is a harsh reality of the software engineering process. Writing tests for feature code is often more time consuming and necessitates more complexity than the application code that is being tested. There are hundreds of reasons that software engineers use to avoid writing tests, and most of them boil down to a misplaced prioritization. When a bug does make it to production, we find it's a more productive dialogue when we ask "why was this not caught in testing?"

Problems of companies that lack Testing

Many methodologies have developed in the Software Engineering world around testing to try to keep teams on track. TDD, DDD, BDD, to name a few. In our opinion, these are all looking at the same existential problem and proposing a doctrine for absolution; the problem is clear: we need to be writing more tests.

Companies who haven't yet prioritized testing experience:

• Engineers of all skill levels making unpredictable changes and product regressions that cause stress and chaos in the organization
• New engineers have trouble onboarding because they don't have bite-sized pieces of code to analyze.
• An increase in failed releases, downtime, and reputation damage
• Increased cognitive complexity for software engineers, leading to burnout
• Inadequate documentation and increased confusion around software systems

Tests are crucial and should be encouraged required at every stage of the development process. They should be easy to maintain and self-documenting. Better yet, they should be integrated into the integration pipeline to ensure that releases proceed only under stable circumstances.

How does this Affect Developer Experience?

To change load-bearing code in an application can be tricky, and the best software engineers know to do so with extreme caution in the form of tests. Regardless of the size and scope of change being implemented, when load bearing code is modified, there's a risk that it gets worse, not better, and that can be an anxiety inducing prospect for a programmer. Testing helps your developers build with confidence. They often consecrate the intention of a piece of code, and reduce the demand for developers to spend hours writing documentation. In some sense, a test is worth a thousand words, and that value is tremendously consequential to the developer experience.

Logging and Monitoring

What is it?

Logging, monitoring, and tracing are complementary practices that provide visibility into the health and performance of your software systems. Each plays a distinct role in ensuring the smooth operation of your infrastructure, and provides your engineers with the information they need to redesign and debug your systems.

Logging - involves capturing and storing information about events that occur within your systems. Logs provide an historical record of system behavior and can be used for troubleshooting, auditing, and compliance purposes.

Monitoring - involves analyzing data collected from your systems in real time to identify potential issues before they cause outages or performance problems.

Tracing - involves tracking the flow of data through your systems, and pointing out causal relationships in different parts of an application or applications. Tracing is particularly useful for troubleshooting distributed systems and identifying bottlenecks.

Why is it Important?

Implementing LMT gives engineers the power to inspect systems to draw conclusions about a multitude of variables that materially affect the user experience. User behaviors can be analyzed and interpreted to improve the feature development process; performance and availability data can be used to preemptively scale and optimize to improve system availability. Your engineering team will move faster with LMT because they'll spend less time tracking down and attempting to reproduce errors.

When LMT is implemented correctly, you'll see:

• Improvements in the long-term health and stability of your product
• Faster troubleshooting and error resolution
• Quicker user experiences, and less performance degradation over time.
• Non-technical stakeholders within the company actively engaged in monitoring the parts of the system that they most frequently use
• Quantitative conversations, rather than qualitative ones regarding user experience and performance
• Less downtime, faster troubleshooting, and enhanced security

For more information about how to improve your teams rate of success, checkout our examples of a MVP

Problems of Companies that Lack Sufficient LMT

In modern software products, we're often just a few steps away from having a robust LMT system. Modern programming languages and cloud services provide barebones, unstructured runtime information in most cases, but those solutions tend to be insufficient mapping the behavior of a complex software product on their own. They often need to be consolidated and massaged useful schemas, and communicated via data visualization tools.

Companies that lack sufficient LMT often experience:

• Reactive firefighting, where engineers are constantly responding to urgent support tickets, leading to extended downtime, frustrated users, and loss of revenue.
• Slow troubleshooting, where delayed resolution impacts the scope and duration of the problem
• Performance regressions and flakes, where systems experience recurring, unexpected availability issues that are difficult or impossible to reproduce

Contributing to a software product without adequate visibility into how it works is a recipe for distress. It negatively affects your product, and the engineers who work on it. By prioritizing LMT, you'll give your engineers the tools they need to spend less time addressing support tickets, and more time building the features your customers actually want.

How does this Affect Developer Experience?

When software engineers are required to operate in systems that lack sufficient visibility tooling, they spend a lot of time anxiously tracking down bugs, knowing that after they're found they need to be fixed. LMT gives engineers the peace of mind that even the flakiest bugs have been captured, and that the information surrounding the cause of the bug will persist. It reduces the need to immediately context switch. In a great LMT system the information needed to identify the cause of a bug will have already been surfaced and expressed in documentation or an easy to grok visualization, allowing the team to focus on FIXING rather than FINDING the problem.

Final Thoughts

Measuring the quality of your developer experience can, if done correctly, help surface deeper structural and technical problems in your organization that once addressed will have a tremendous impact on your business. Working towards a superb developer experience can lead to a more efficient team, because the things that make developers happy are often the things that reduce their cognitive load, and create reliable, safe mechanisms for building software.

If you're interested in improving your software developer experience and getting more from your team, schedule a consultation with us.