Three steps to achieving greater developer productivity
Technology companies are battling to secure – and retain – the best developer talent. Even as the economic downturn continues, the demand remains sky-high. So what sits at the core of creating a happy, fulfilled, and productive team of developers? A great team culture powered by collaboration, productivity and ownership.
One of the challenges to this is when developers have to toggle between different tools, many of which aren't fit for purpose when it comes to today's highly complex tech stacks. According to the New Relic 2022 Observability Forecast, most (83%) respondents in ASEAN used four or more tools to monitor the health of their systems, with over a third (39%) saying that they still primarily detect outages manually or from complaints.
Inadequate or multiple tools make it harder for teams to quickly identify issues before they hit production and accelerate engineering velocity. The result is frustration and reduced productivity. Instead, developers must be provided with the best tools and technology in order to do their best work.
When it comes to traditional software delivery, code is tested much later in the development lifecycle and, most of the time, very close to the release date. As a result, bugs are also found much later in the process.
Developers want to be able to discuss, review and understand code, and invite their teammates to collaborate directly from the integrated development environment (IDE). A better approach is to "shift left" by using observability much earlier in the software development lifecycle to debug, test and evaluate.
By taking this approach and using code-level metrics to optimise their releases, development teams can streamline the way they develop code. They can find and fix bugs, work out how to measure code performance and get it working correctly much earlier in the process.
Developers who can collaborate effectively don't consider their work to be "development complete" until they determine how to measure things and get them launch-ready. It's not just about writing code and shipping it off; it's also about ensuring that related matters, like alerts, are considered and planning for how their code will work after the release.
Creating an environment for productivity
Because developers spend most of their time in the IDE, they must have all the telemetry data necessary to create visibility across their applications. This means bringing telemetry data to where developers build so meaningful data can be accessed without leaving the IDE.
Code-level metrics enable developers to see how individual functions perform in real-time. It's not just about production telemetry; it's also about seeing issues in pre-production, staging or development. The visibility created by shifting left removes the need to manually find errors within code while creating visibility into how different sections are performing, thanks to real-time feedback.
Another approach that complements observability is automation. "Everything-as-code" is important because many mature customers do everything via automation - such as deployments - but are still manually creating alerts, dashboards, and other elements. By bringing automation into the game earlier, developers writing code begin to think about how they measure that code and get it to work correctly.
Instilling a culture of ownership
According to the book Applied Software Measurement, Global Analysis of Productivity and Quality by Capers Jones, 85% of bugs are introduced during the coding phase, long before testing and release are completed. With the cost of fixing defects after production release up to 640 times higher compared to when they are in development, it's clear why technology teams must adopt observability at the start of the software development lifecycle (SDLC).
By integrating observability into the beginning of this process, the impact on the business bottom line is not only significant but could also prevent teams from burning through multiple full-time developer headcounts due to delayed code release and testing. This approach results in fewer defects in production; making it a much more cost-effective way to address issues and reduce the overall volume of errors.
Happy developers are a necessary component for any successful project, which is why it's crucial to instil a culture of code ownership from day one. Talented software engineers are an invaluable resource, and with high staff turnover having the potential to cause significant issues, this culture will reduce the likelihood of discovering problems weeks or months after the code is released.
In the New Relic 2022 Observability Forecast, more than half (51%) of ASEAN respondents said they believed observability increases their productivity and enables them to find and resolve issues faster, with about four in ten (39%) saying that observability enables cross-team collaboration.
When using just the bare bones elements of observability, developers may see roughly where an issue is, but if they aren't diving deeper or shifting left, they aren't creating the best outcomes for their teams. The teams that find bugs - or performance bottlenecks in their releases regularly - are much more likely to trace where those issues are earlier if they shift left with full-stack observability. This enables developers to spend less time on incidents, be productive, increase satisfaction, and free up time for them to work on more interesting and valuable features.