At some point in your career, your organization will be faced with a challenge to improve the quality of your software. Software quality problems can surface when a customer experiences an outage, when a high-ranking executive finds a product defect, or even when there isn’t any visible problem at all! Whether you are an individual contributor, a product leader, an executive, or engineering manager, you may be asked to understand the quality of your software and how you can improve it.
I started my career in software testing which gave me an early understanding and deep appreciation for software quality. Quality evolved from tactical and reactive to strategic and proactive as my role evolved:
Individual contributor tester - find as many defects across a breadth of areas (functional, accessibility, globalization, security, etc.). Push to get those defects fixed and automate the defect detection process.
Individual contributor developer - write code in anticipation of avoiding defects. Being a former tester helped greatly!
Line manager - hold the team accountable for writing code to avoid defects. Execute on quality improvement plans.
Manager of managers - influence and impact quality across my peer group, not just within my team
Organization leader - create shared understanding of quality, develop strategy, objectively improve quality of one or more products or organizations
Unlike other areas with well-defined maturity models (e.g. DORA for DevOps, CMMI for software development), I couldn’t find well established models for quality. I’m writing this in hopes of sharing what I’ve learned and inspiring others to share more with me to broaden my understanding on this topic.
Before exploring software quality in depth, the most important point to take away is that software quality is not a “point in time” problem, even if it may be presented to you like this. Quality should be a journey, and part of your team culture. There is no end state, because the product and code keeps evolving and your understanding and ability to measure your software quality will also evolve.
How do you know if your organization has a culture focused on software quality?
Quality is one of your team’s or leader’s stated values
Multiple layers of management up through executive leadership are accountable for quality and hold their teams accountable
Incentives to improve software quality are aligned with performance reviews and rewards
Quality is measured both objectively and subjectively, and is continuously improving
Quality is regularly discussed in team meetings, quality reviews, and business reviews
Since we think of quality as a journey, I believe many organizations stand to benefit from a more measured approach on assessing their quality culture and how to improve it. Over the next several posts, I’ll break down that journey into a series of posts. You can read them all or narrow in on the part of the journey that applies to you or your organization.
The steps of a quality journey:
Define software quality - get everyone on the same page
Create a strategy - what, so what, now what
Rhythm of business - monitor progress and celebrate wins
Measure, fix, repeat - actually do the work :). I’ll share some case studies to make things concrete.
Shift left - prevention and earlier detection of quality issues
Raise the bar - keep improving by setting more ambitious goals.
I led this post by saying the audience is broad. Based on where you are in the organization, take a look at these steps and understand the role you play to improve your organization’s quality culture. If you’re a leader, you may be focused on quality definition, strategy, and establishing rhythms. If you’re an individual contributor, you can use those frameworks to measure & fix some areas, raise the bar in others, or shift quality left. The primary reason you should care about this is that it will benefit your users and your product. And because improving quality benefits your users and product, it will naturally benefit you and your career growth!
I’ll leave you with a few quotes I’ve learned from different organizations that I’ve repeated to my teams to keep quality top of mind:
“The most important features are the ones you’ve already shipped”
“Quality, quality, telemetry…Quality processes for customer perceived quality outcomes measured by continuous telemetry.”
“Quality over dates”
In the next post, I’ll define software quality in detail to help you create a consistent mental model and shared understanding of quality in your organization. Stay tuned!
Repeatability, Cost, and Systematic coverage approaches are important undertones in all this. With the shift towards being data driven / data informed, moving away from things like "soak" to something more measurable as a gate is important.
In my experience attention to quality is a cultural trait that’s pervasive in an org. When I see a bunch of slides and docs from the dev teams with typos all over the place it shows up in the code too. Sounds extreme but quality conscious people do so in everything they ship - not just code. Great article D.