Developers, unite! Join the fight for code quality

Advocating for quality code isn’t always easy, because management doesn’t always care. But it’s the only way to build good things that deliver on their promise.

 

By Jeremy Duvall, founder, 7Factor Software
This article originally appeared on InfoWorld on March 20, 2023.

 

For software engineers, a vote for quality isn’t always on the institutional ballot. Sometimes (too often) the sole metric for success is speed. The directive goes: Get your code out the door ASAP and leave the pesky testing to quality assurance. In fact, in many organizations, QA exists as a separate office from development, with stilted communication stumbling sporadically between the two groups.

But while the powers that be may have deemed this separation optimal for deploying at hyper speed, it ultimately works to the detriment of the software’s short-term readability and long-term extensibility. To optimize those two elements, quality must belong to everyone, perhaps even especially to developers. If you’re a software engineer and your organization doesn’t expect it from you, it’s still in your best interest to both prioritize and promote quality code.

This is easier said than done, and you certainly must play the long game to build consensus among leadership. Changing minds, particularly when profits and livelihoods are involved, is no simple task. But just as speed can function as the enemy of quality, so too can an expectation for quick results prematurely thwart the case for quality at your organization.

Let’s examine why quality is important in the first place—and how you can stand up for what’s right without jeopardizing your job.

Why is quality important?

Reason #1: Quality is the quickest path to value

Whether you’re representing a partner organization or working as a member of an in-house development team, advocating for quality is about upholding the value that clients and executive leadership teams are paying for. What we’re building with code is software, and software is meant to be used by other human beings. If it’s laden with bugs and/or crashes anytime someone looks at it funny, we have failed to deliver value to users, and by extension, to the clients for whom we built the software.

And even if the latest feature makes it out the door without any catastrophes, if the process incurred ample technical debt, neither the product nor the teams that built it are set up for success when adding or enhancing features down the line.

Reason #2: Quality is brand protection

In addition to the long-term value of an individual product, quality also safeguards your employer’s brand equity in the long run. Developing a reputation for implementing poor code is simply bad for business—and it only takes one or two unsuccessful launches to erase years of good work and word of mouth.

“Only 59% of users think it’s possible for a company that serves a poor user experience to deliver a quality product,” writes John Kelly in CIO. “For example, if your business is cell phones, and you have a confusing ordering platform, 41% of customers will assume you make bad phones... One error destroys trust.”

Losing customer trust negatively impacts all of your employer’s offerings—past, present, and future. A blow to brand incurs far more financial damage than any one project budget, and the road to recuperation is equally costly.

Reason #3: Quality is craft

Writing good code is a craft as much as any other, and should be regarded as such. You have every right to advocate for an environment and an operational model that respect the intricacies of what you do and the significance of the outcome.

It’s important to value, and feel valued for, what you do. And not just for your own immediate happiness—it’s also a long-term investment in your career. Making things you don’t think are any good tends to wear on the psyche, which doesn’t exactly feed into a more motivated workday. In fact, a study conducted by Oxford University’s Saïd Business School found that happy workers were 13% more productive. What’s good for your craft is ultimately best for business—a conclusion both engineers and their employers can feel good about.

Reason #4: Quality is the right thing to do

Software plays a big role at just about every level of society—it’s how we create and process information, access goods and services, and entertain ourselves. With the advent of software-defined vehicles, it even determines how we move between physical locations.

With that central role comes a high degree of responsibility. The emerging field of software engineering ethics aims to enumerate some of the ethical responsibilities to which developers should hold themselves accountable. That includes building products that do no harm while also ensuring a foundation of quality. The Software Engineering Code of Ethics and Professional Practice, for example, stipulates that “Software engineers shall ensure that their products and related modifications meet the highest professional standards possible.”

While ethical questions certainly bring their fair share of debate, basic standards of quality are less ambiguous. We know that many of the products we create come with increasingly high stakes, and it’s our obligation to make sure that they can perform reliably and effectively for people, even when that level of quality assurance isn’t an explicit part of our job description.

So how do you make it happen?

At this point, you might be thinking, fine, the case for quality is clear enough. But good luck convincing the powers that be! How does one actually advocate to leadership for more testing and quality assurance from within the development team?

The point isn’t to draft out and mass distribute a furious yet rousing manifesto, Jerry Maguire-style, but rather to communicate meaningfully with the goal of building consensus over time. Consensus is a key component to good software engineering, after all. Bad software engineers come to the table with inflexible viewpoints on which solutions will solve problems. Good engineers share their input and find solid common ground to drive important decisions.

You probably already build consensus with your peers all the time. Do we move this direction for our MVP? Do we go that direction for writing our API? How do we architect our pipelines so that we can get things into production faster?

Building consensus, however, is something of a lost art in our highly polarized cultural milieu. With endless expectations for faster and faster results, few have the tools (and patience) necessary to manage prolonged give-and-take, particularly with the added power dynamics of talking to leaders. But with persistence, patience, and a deliberate, strategic approach, you can build consensus around the importance of quality.

Building consensus 101

Step #1: Frame your concerns in the interests of your company and your clients

If you want the higher-ups to hear you out, you have to speak their language. What are the top-line objectives for the C-suite? If you can draw a clear line back to those goals, leaders will have a tangible motivation to consider a new approach. In the end, more emphasis on quality is for the good of the project, and that increases the value of the exercise for your company, for your client’s company (if applicable), and for the end user. So this is a case you can absolutely make.

Step #2: Try to see things from your leader’s point of view

If the person above you seems extra averse to your proposal, remember that livelihoods are at stake. If they’ve been tasked with a certain target (probably around deployment speed), and your request seems to put that target in jeopardy, defenses will be on high. And why shouldn’t they be? At the end of the workday, your manager has to go home and put food on the table. Even if this person agrees with you in theory, they still have to balance your ideas against the significance of gainful employment.

Mindful of that reality, what better compromise can you offer your leaders to raise quality standards without risking their job?

Step #3: Move the quality conversation from opinions to facts

Beyond advocating for more time or raising ethical concerns, automated testing has a big role to play in maintaining code quality. By writing and conducting your own unit tests, you free up the QA team to focus more squarely on user acceptance testing (UAT). The test itself also creates a source of documentation to settle any disputes.

For example, let’s say QA comes back claiming to have found a technical bug, but in your view, they’ve simply misinterpreted or misunderstood the technical requirements at play. You can point to your test to demonstrate that the code does in fact operate as intended, keeping the conversation objective for all parties—and making quality a point of fact rather than a struggle of opinions.

Step #4: Remember, you’re negotiating toward consensus

Empathy with leadership will get you far—but it probably won’t get you everywhere. Make sure you have a realistic metric for success. Negotiating is all about the give-and-take. Maybe you only inch them 10% closer to a process that truly values quality code. Rather than throw in the towel, appreciate the progress and think about how you can gain another 10% next time. It’s critical to play the long game and remain open to other points of view.

Is it time to look for another job?

In your conversations about quality, it’s likely that good people will bring up a range of viewpoints, and ultimately leadership makes the call. Compromise is inevitable, and it’s no reason to consider your efforts a failure. But what if you follow the advice above, and yet leadership will not loosen their maniacal grip on sprint velocity metrics? Should you push back … or head for greener pastures?

When do you have to take a hard line, and when is it time to look for a new job?

Ultimately, only you can make that decision. But keep in mind that good leaders listen, and a healthy culture should be able to handle, and even embrace, multiple points of view. An organization resistant to pivoting, even in small ways, toward a healthier way of developing software is probably not the best place for you to learn, grow, and write good code.

Quality is worth the effort

The quest for quality has all the makings of an epic professional journey. You’ll get better at writing and automating your own tests. You’ll expand your communication skills. You’ll take in new points of view and hopefully forge stronger working relationships across the aisle and up the food chain. You’ll stand up for what’s right, championing quality the best way you know how across your organization. And at the end of the road? Newfound freedom to build more good things that make life that much easier for the people that use them.