For software engineers, a vote for quality isn’t always on the institutional ballot. Sometimes (all too often) the only metric of success is speed. The directive says: Get your code out ASAP and leave annoying testing to QA. In fact, in many organizations, quality control exists as a separate office from development, with forced communication that stumbles sporadically between the two groups.
But while the powers that be may have deemed this separation optimal for implementing at hyperspeed, it ultimately works to the detriment of short-term readability and long-term extensibility of the software. 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 this of you, it’s still in your best interest to prioritize and promote code quality.
This is easier said than done, and you certainly need to play the long game to build consensus among leaders. Changing minds, particularly when it comes to earnings and livelihoods, is not an easy task. But just as speed can serve as the enemy of quality, the expectation of quick results can also prematurely defeat the case for quality in your organization.
Let’s examine why quality matters 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 fastest path to value
Whether you represent a partner organization or work as a member of an internal development team, advocating for quality is about championing value that customers and executive leadership teams pay for. What we are building with code is software, and software is meant to be used by other human beings. If it’s full of bugs and/or glitches every time someone sees it weird, we haven’t been able to deliver value to the users and by extension the customers we build the software for.
And even if the latest feature is released without any catastrophe, if the process incurred a lot of technical debt, neither the product nor the teams that created it are poised for success in adding or improving features in the future.
Reason #2: Quality is Brand Protection
In addition to the long-term value of an individual product, quality also safeguards your employer’s long-term brand equity. Developing a reputation for implementing poor code is just bad for business, and it only takes one or two failed releases to erase years of good work and word of mouth.
“Only 59% of users believe it is possible for a company that provides 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 defective phones…A mistake destroys trust.”
Losing customer trust negatively affects all of your employer’s offers: past, present, and future. A brand hit inflicts far more financial damage than any project’s budget, and the road to recovery is just as costly.
Reason #3: Quality is craftsmanship
Writing good code is as much a craft as any other, and should be considered as such. You have every right to advocate for an environment and operating model that respects the complexities of what you do and the importance of the outcome.
It is 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. Doing things you don’t think are good tends to wear down the psyche, which doesn’t exactly fuel a more motivated work day. In fact, a study by Oxford University’s Saïd School of Business found that happy workers were 13% more productive. What’s good for your craft is ultimately what’s 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 an important role at almost every level of society: it is the way 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 must hold themselves accountable. That includes building products that do no harm while ensuring a quality foundation. 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 possible professional standards.”
While ethical issues certainly bring their fair share of debate, basic quality standards are less ambiguous. We know that many of the products we create have high stakes, and it’s our obligation to make sure they can work 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, well, the case for quality is clear enough. But good luck convincing the powers that be! How do you actually advocate for leadership for more testing and quality assurance from within the development team?
The point is not to write and mass distribute an angry but moving manifesto, à la Jerry Maguire, but to communicate in a meaningful way with the goal of building consensus over time. After all, consensus is a key component of good software engineering. Bad software engineers come to the table with inflexible views about which solutions will solve the problems. Good engineers share their input and find strong common ground to drive important decisions.
You probably already build consensus with your peers all the time. Are we moving in this direction for our MVP? Are we going in that direction to write our API? How do we design our pipelines so we can get things into production faster?
However, building consensus is something of a lost art in our highly polarized cultural environment. With endless expectations of faster and faster results, few have the tools (and the patience) to manage prolonged give-and-take, especially 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 customers
If you want those at the top to listen to you, you have to speak their language. What are the main goals for the C-suite? If you can draw a clear line toward those goals, leaders will have 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 to your company, to your client’s company (if applicable), and to the end user. So this is a case that you absolutely can make.
Step #2: Try to see things from your leader’s point of view
If the person above you seems more reluctant to your proposal, remember that livelihoods are at stake. If they’ve been assigned a certain target (probably around deployment speed), and their request seems to jeopardize that target, defenses will be up. And why shouldn’t they be? At the end of the workday, your boss has to go home and put food on the table. Even if this person agrees with you on paper, he still has to balance his ideas with the importance of gainful employment.
Aware of this reality, what better commitment can you offer your leaders to raise quality standards without risking your job?
Step #3: Move the quality conversation from opinions to facts
Beyond advocating for more time or raising ethical concerns, automated testing has an important role to play in maintaining code quality. By writing and performing your own unit tests, you free up the QA team to focus more directly on User Acceptance Testing (UAT). The test itself also creates a source of documentation to resolve any disputes.
For example, let’s say QA comes back claiming to have found a technical error, but in their opinion, they simply misunderstood or misinterpreted the technical requirements at stake. You can point to your test to show that the code does, in fact, work as intended, keeping the conversation objective for all parties and making quality a fact rather than a battle of opinions.
Step #4: Remember, you are negotiating towards 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. Trading is all about giving and receiving. Maybe it only gets them 10% closer to a process that really values code quality. Instead of throwing in the towel, appreciate the progress and think about how you can earn another 10% next time. It is essential 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, good people are likely to present a variety of viewpoints, and ultimately leadership makes the decision. Compromise is inevitable and is no reason to consider your efforts a failure. But what if you follow the advice above, and yet the leadership doesn’t loosen their maniacal grip on sprint speed metrics? Should he back off… 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 must be able to handle, and even accept, multiple points of view. An organization that resists turning, even in small ways, toward a healthier way of developing software is probably not the best place to learn, grow, and write good code.
The quality is worth the effort
The pursuit of quality has all the makings of an epic career journey. You will get better at writing and automating your own tests. You will expand your communication skills. You’ll gain new insights and hopefully forge stronger working relationships down the aisle and up the food chain. You will stand up for what is right, standing up for quality to the best of your ability throughout your organization. And at the end of the road? New freedom to build more good stuff that makes life a lot easier for the people who use it.
Copyright © 2023 IDG Communications, Inc.
Be First to Comment