Overcome These 3 Hidden Barriers to Developer Productivity – InApps Technology 2022

Engineering teams are on a constant hunt for increased productivity. Approaches like DevOps and agile are popular among engineering teams as they help to keep things moving forward through dedicated collaboration, communication and goal-setting. While these methodologies can make a difference, there are other barriers to developer productivity that fall outside simple workflows.

The three barriers described below can occur in different aspects of an organization’s operations, but their impacts on developer efficiency and productivity can limit the team’s ability to deliver value to the customer just as much as workflow inefficiencies.

In many cases, the hidden barriers to developer productivity are nagging problems that have gone unaddressed for months or years. The effect of these problems can be easily underestimated or forgotten, but they have a tangible impact on the organization’s performance and bottom line. Additionally, these problems can lead to more foundational issues like reduced morale, staff frustration and increased attrition on engineering teams.

1. Context Switching Between Tools and Platforms

A decade ago, when teams collaborated on a single document, they would take turns working in a single Microsoft Word file. With each revision, the editor would need to make suggestions using tracked changes, attach the updated file to an email and send it to the team. When documents were expected to be shared within a large team or sent through an extensive chain of approvals, this process became cumbersome and often led to mistakes due to version control failures.

Of course, this Microsoft Word example is now a thing of the past. Tools like Google Docs and Microsoft 365 allow multiple editors to comment on and discuss the same document simultaneously, putting collaboration directly where it belongs: in the document itself.

However, the outdated Microsoft Word example offers a relevant analogy for many current developer environments. While tools like GitHub, JIRA, Terminal and Slack each offer value to developer teams, they require developers to switch context between multiple tools. Frequent context switching results in countless hours of distraction, with a dramatic negative effect on developer velocity. The developer’s solution — the Google Docs or Microsoft 365 of engineering tools — are extensible integrated development environments (IDEs), which integrate essential, yet disparate tools into a single workflow.

2. Institutional Knowledge Gaps

What happens when your most experienced developers leave the company? For many companies, this kind of departure takes a tremendous amount of institutional knowledge with them, leaving their replacements to spend hours figuring out how existing code works instead of solving new problems. Before the increase in remote work brought about by COVID-19, this situation was even more pronounced. Institutional knowledge traded hands in hallways and offices, and written documentation did not play a major role in knowledge sharing.

With new hybrid work environments and the rise of collaborative tools like Slack or Discord, relevant discussions are now written down and saved in a searchable database. However, these tools were not designed to be knowledge repositories, and it can be difficult, if not impossible, to quickly track down key information when it’s needed.

Organizations must work to preserve institutional knowledge through new approaches to codebases and documentation. Innovative new tools can capture the collaboration and conversation connected to a specific piece of code, attaching it to the code and essentially building an annotated codebase from which new employees can learn.

These tools can also soften the blow when a key employee leaves. While the owner of a piece of code may no longer be at the company, all the discussion about their code will be saved in context as annotations to their codebase, where it’s most helpful to their replacements.

3. Troubleshooting in Context

DevOps practices make it easier for teams to understand the operations of their personnel. However, a lack of visibility into the tech stack itself can limit the benefits of a DevOps approach.

Many developers are limited today by a push-and-pray mentality, deploying code to production without a clear understanding of how it’s performing or how that deployment changed other aspects of performance, like error rate and customer experience. It’s understandable why this happens. If someone is faced with a code review of 1,500 lines of code, it can be tempting to scan it and give a stamp of approval to the entire review. However, even if 1,495 lines of code aren’t critical, the remaining five could have material performance implications.

Developer teams must use in-IDE observability to be able to troubleshoot their tools in context. Making observability and production telemetry an essential part of the developer’s daily workflow will allow teams to immediately assess the impact of changes to their code.

For developer teams, increased velocity and transparency are always worthwhile pursuits. However, it’s important to not maintain a myopic focus on workflows when other nagging problems could be hiding in plain sight.

By making a commitment to production telemetry, developer teams can adopt an objective, data-driven approach to software engineering — saving time and avoiding potentially misguided approaches based on opinions rather than facts. Visibility, transparency and velocity can help engineering teams to meet ever-increasing requirements and provide the best possible business outcomes for their organization.

Photo by Andrea Piacquadio from Pexels.