Balancing code quality and developer productivity
On the surface, tech leaders might perceive code quality as a technical aspect of software development while viewing developer productivity as a human resources issue. In fact, they are intertwined and should be addressed concurrently.
Considering that technical debt wastes 23-42% of developers’ time, it’s crucial to understand and refine the relationship between code quality and developer productivity, so let’s dissect the factors influencing this relationship and talk about how to balance the two:
What are common code quality issues?
In order to better assess solutions, let’s take a closer look at prevalent code quality issues which often translate to lower developer activity:
This issue may not be the most complicated since it’s the equivalent of a typo, like pressing the wrong key or forgetting to close brackets. However, it does end in the computer failing to understand what you want it to execute. Since such minor mistakes often cause syntax errors, it can be laborious sifting through lines of code to find what's missing or incorrect.
Inadequate descriptive elements
Such a problem often manifests in two ways. First, the purely descriptive sentences tell the reader what a specific bunch of code lines does and the nuances in how it's executed when conditions or objectives vary. Without these descriptions, another developer may not quickly scroll to the piece they want to modify.
They'll have to read huge chunks of code to determine which lines are responsible for particular actions. The second example of this problem deals with the more instructive lines.
It can be something like an unhandled exception, where you lay out logic, yet a different situation could leave the computer not knowing what to do, but then you forget to write down the alternative course of action. Another example here is an unchecked input.
Overly complex code
Code complexity might be subjective, but it does become a problem for many. Sometimes you read several lines of code and everything makes sense immediately. But then you get to a certain section, and the writer has used a very convoluted approach to doing something short and straightforward.
That spawns more inquiries and makes it harder to find any other faults within that code section. For example, complex code often includes several if/else statements and nested loops.
This is an instance where you find multiple copies of the same code lines pasted in different areas of the code where they aren’t applicable or need alterations.
Incomprehensible sequences and structures
Some developers write code that works well but could be better organized. For example, you find different pieces that trigger distinct actions, but they aren't arranged in the proper sequence.
Here, code is written to exist as one piece. Consequently, it's hard to isolate a single component that does one complete task and reuse it elsewhere. You can’t easily enhance one element without adversely affecting how other parts work.
Code security is a very challenging issue, especially since numerous ways to compromise a program exist. For example, some coders may create contradicting rules that eventually give access to more people than they'd want, while others may not conceal secrets like API keys. Generally, code security may arise from flawed logic or handling information recklessly.
Flawed memory and CPU usage
Occasionally, code quality can be gauged as poor if small and simple functions are written so that they require lots of memory or processing power. However, this issue is also subjective since some argue that certain functions will inevitably require more resources and that it’s up to the end user to have a better device.
Others say there are ways to reduce the resources the code uses, but they are more like tradeoffs, where you lean more on one resource and use another less.
In this case, the code has been written with the presumption that it will return a specific output once executed, but upon execution, it doesn't. The output could be missing, different from the expected, or totally incoherent.
Factors affecting code quality
To determine what we can do to improve code quality, we should be aware of the common causes of the code quality issues mentioned above. These include:
Among developers, knowledge gaps often take on two types. The first is where a developer partially knows how to use a particular programming language. The second is where a developer is proficient in a particular language but needs to translate code from that language into one they know little about or vice versa (translating code from a lesser-known language to a familiar one).
Poor organizational culture
Whenever a software development company is poorly organized, there’s no clarity on whose responsibility it is to ensure quality. As a result, the technical staff involved in creating and handling code will do the bare minimum and pass on the burden to the next person who has to deal with their work.
Some organizations have team leaders obsessed with saying they did it fastest. They assume that the market has to know you before they know the competition, and you can sort out any issues after. Unfortunately, this mentality leaves developers less concerned with writing code neatly and more fixated on producing it rapidly.
Absence of pre-established rules and quality checks
Even when a company is organized and has people in charge of quality assurance/control, they still have to establish standards that the work product must meet to be considered high quality. However, quality is quite debatable.
Some developers may lay down lots of jumbled code but contend that if they can make sense of it, any other developer with their level of expertise should. But when working as a group, one person's standards can hardly be everyone else's. And if you don’t come together and agree on a mutual definition of quality, complaints eventually arise.
Many developers have unique approaches to coding and may not be so open to working with others as they believe it slows them down. Unfortunately, when working on group projects, they could miss out on some valuable insight and end up putting out code lacking in one way or another.
This is another factor whose influence on code quality isn’t straightforward. For example, a monolithic architectural approach can hamper code quality as developers pack too many objectives into one chunk of code and create a web of unnecessarily intertwined and inexplicable components.
And on the other hand, a microservices approach could leave a team dealing with multiple modules written by different people in varying ways, with unpredictable errors. Basically, you could increase the code sources, which widens the sample space and heightens the probability of encountering shabby code.
Factors affecting developer productivity
To balance code quality and developer productivity, we also need to know the factors influencing developer productivity and find the intersection between them and those affecting code quality. On that note, low developer productivity is often the result of the following:
Whenever there are various sources of truth, developers are bound to spend some time figuring out why they differ and which one to rely on. This may be rare at the start of a project, but conflicting data can become a big issue as the building progresses.
Software development projects can be costly, and often, workloads exceed the number of people available to tackle them. This leaves leaders pushing developers to cover more ground, and they eventually get into a loop where they shuffle through tasks quickly, only to revisit them because they weren’t done correctly.
Some tools may offer tremendous utility and be very user-friendly but lack a few critical features related to code quality, such as automatically detecting and excluding secrets from repositories, highlighting syntax errors, and more. Subsequently, they leave the developer having to do many more quality checks manually.
This is a situation where developers are constantly in flux as their leaders change the project goals, introduce new administrative procedures and tools, and rearrange the priority of near-term tasks. As a result, context switching messes with developers' ability to focus on a single task and perform it accurately and in the shortest time possible.
Sometimes, project managers hold meetings or send messages regarding subjects with no new developments. And while they mean well, such communications can be very distracting, especially if they don't have any meaningful calls-to-action attached or don't produce any resolutions.
Balancing code quality and developer productivity
When trying to balance these two, it's vital first to identify the practices you'd have to institute to improve code quality, irrespective of whether you have a developer productivity problem. You can start by
Conducting practical tests during recruitment
Try tweaking your recruitment process by inserting real-world scenarios where a candidate must perform a coding exercise from scratch with minimal instructions and review a piece of code with quality shortfalls. That will clue you in on how much inherent discipline the developer has when coding and their ability to improve poor-quality code.
Once you've assessed them, you can involve them in additional training or sharing exercises where they polish their skills and get ready for more technically demanding projects.
Meeting to set coding standards
While these meetings may be viewed as exercises for establishing what rules to follow, they are more than that. For the non-technical staff, these meetings enlighten you on how developers think and their priorities when working. In addition, you can note what they agree not to follow and learn more about managing their collaborative efforts.
But ultimately, having a clear quality checklist makes quality assurance easier since those in charge can follow a simplified system and even rate the code. That comes in handy when profiling developers and understanding the areas where they may need help.
Having regular code reviews
When you have regular code reviews, you may feel like you’re spending too much time reviewing code. However, you are likely reducing the number of issues you can find at any given time since you’re dealing with smaller pieces of code at a time.
In contrast, when you let code pile up before you review it, you’ll probably have to put some extra work into deriving a system for doing this massive work.
Additionally, you might spend more time pinpointing the source of a specific issue in cases where multiple pieces of code are highly related.
Measures that address both code quality and developer productivity
To improve code quality and developer productivity simultaneously, you can:
Automation undoubtedly reduces developers’ workload by taking over the more repetitive tasks. It also lessens the risk of human errors, like wrong entries or forgetting to perform a particular coding step. Moreover, teams can use it to detect secrets or missing characters during or after a coding stint.
Automation can also transcend fixing coding issues and go on to continuously improve developer performance. How? Well, whenever a process is automated, you can compare the speed and accuracy to that of an equivalent manual process.
Subsequently, you get to see the discoveries made by automation tools, the steps involved (be it strictly sequential actions or handling batches of tasks simultaneously) and the explanation of why events unfolded a certain way. So eventually, developers can refine their strategies to limit the errors made where possible and become faster at identifying those that exist.
This effort starts with senior developers or team leaders, who should understand each developer’s strengths and weaknesses and group them in such a way that they complement each other.
Firstly, you should ensure you're not putting too many people on one task and leaving others stagnant. Secondly, you should select tools that properly lay out every participant's contributions with captions and notifications so that team members have more flexibility in how they add to the work.
Select cohesive tools
Engineers are often very proactive when solving problems. Together with other team members, they identify cutting-edge tools that help them achieve some near-term goals. However, some of these tools don’t properly align with the broader mission and can produce new challenges in the long run.
For example, some tools may complicate communication between team members collaborating on rapid iterations that involve a lot of messaging and file sharing. Additionally, they may not offer coherent change tracking and notifications, leaving members spending more time trying to figure out who did what and when.
Some tools may also be unable to seamlessly integrate with other important tools introduced later, leaving developers having to write code for these integrations or switch back to earlier alternatives and transfer any recent work back to other tools. And don’t forget other issues like some SaaS tools having limits on the number of user accounts a team can have under certain feature packages/price plans.
By selecting cohesive tools, developers spend less time trying to link incompatible tools, transferring work from one environment to another and converting it into a suitable format for its destination. Cohesive tools also minimize the risk of diminishing data integrity, which can happen during conversions and transfers.
And remember, cohesive tools also make it easier to bring business leaders into the fold so they have a clearer picture of the progress being made and the factors affecting task completion, thanks to frequent notifications, reports and analyses.
Break down deliverables
When communicating the desired results to developers, dev leaders should break them down into smaller finite pieces. For example, a single code commit may cover a few actions in a process but only part of the function and its links to others.
So if you want to keep developers productive, be clear about how many pieces of the puzzle you expect and which ones in particular. Failure to do so could leave developers working in random sequences and forgetting about the problems that could arise from not moving in sync.
Create code templates
If you have any projects with successful products, revisit the approach you used when creating some of the components. Then, create a template from them, stipulating the information to be presented, the order it should be presented, the time it should take, and the number of participants.
Code templates help keep developers within the boundaries of what is needed to get the desired outcome, reducing the likelihood of overly complex code.
Adopt agile practices
Agile software development is a model of delivering higher quality software faster through increased collaboration and flexibility in the order of project task execution. There are plenty of Agile methodologies, frameworks and practices you can try, such as:
- Adaptive Software Development
- eXtreme Programming
- Feature-Driven Development
- Dynamic Systems Development
- Lean Software Development
Hold cross-functional meetings
Get team members in different positions together frequently to reach a consensus on which features to prioritize, set realistic delivery dates, divide labor, and identify the relationships to be cultivated or strengthened to expedite the project.
Stage extra-curricular events
Try to involve developers and other team members in events where they can share and learn from others how to code faster with fewer mistakes. Sometimes trying to learn while in the middle of an actual project can be daunting, so it helps to create a more casual low-stakes setting where ideas can flow more naturally.
Evidently, balancing code quality and developer productivity requires you to pay attention to tools, people, and processes. That takes a far-reaching formula that may vary from one organization to another, so it helps to have professional assistance when pursuing this balance.
That said, feel free to schedule a demo with DeepSource to learn more about our comprehensive solution, which improves security, stability, and developer velocity in software development.