POSTED : October 26, 2018
BY : Concentrix Catalyst

This series of articles is intended to explore how an organization can promulgate a ‘Culture of Quality’ in software engineering. While I will try to explore this topic in easily digestible chunks, it is a huge undertaking. One requiring significant work over the coming months (or even years). Thus, before we embark on this journey, it is important to take a moment and reflect on what we mean when we say ‘Culture of Quality’, so that the end towards which we are progressing is clear and constant and so that we may judge forward progress.

Almost any engineering leader will quickly acknowledge that quality software engineering is impossible to define when it is understood as a standard measuring-stick applied to finished software. First off, one simply needs to ask ‘from what perspective and in what way is the quality of this software to be measured’, and the standard becomes a tenuous one. Software may run perfectly on one mobile device, yet fail to execute at all on some new freshly-released device not in scope when the code was delivered. Software may fit the requirements in every conceivable way, yet may be difficult for a developer building a 2.0 version to read and extend. We may develop software that simply nails every aspect of the client’s UX team design down to the pixel, yet that design may prove to be ill-conceived and difficult for the user to operate.

One may simply (and with good reason) say that the only reasonable way of evaluating the quality of a piece of software is from the customer’s perspective — but here too all experienced engineering leaders will acknowledge the fact that the customer may have shifting demands, timelines and requirements that create significant challenges to development teams attempting to achieve quality engineering.

“Almost any engineering leader will quickly acknowledge that quality software engineering is impossible to define when it is understood as a standard measuring-stick applied to finished software.”

There are, of course, many tools at large in the industry to help define quality metrics for software — and this series of articles will eventually explore that space. However, that does not help us establish a foundational concept of quality in software engineering, one that will help guide us in a comprehensive exploration of all aspects of quality in software engineering. Instead of getting hung up on analysis frameworks and conceptual toolkits, we suggest a different approach to understanding software engineering quality. One that understands the multivariate context of how software is developed, and the wide array of stakeholders that exist in the development of any software. Moreover, one that understands quality in software engineering through process and people at least as much as it understands it through finished software.


This series of articles advocates for a systems view of software quality, where many parts work together to achieve quality in the process, much like how a finely tuned Swiss watch ticks out time.

Understanding quality engineering from this different perspective clarifies our mission. Instead of looking at quality engineering as an objective yardstick for software, we suggest instead to look at it as a particular way of approaching and executing software development. From this perspective, quality engineering looks like an engineering culture that approaches software quality in a full-spectrum way that seeks to assert quality-centric principles and practices at all levels. Such a culture of quality holds each member accountable to best practices and standards, defines roles and responsibilities for the execution of those best practices and standards and captures this network of roles, responsibilities, best practices and accountabilities in a framework for project governance.

Taking a step beyond this core framework, one would expect a culture to construct a shared experience for those who are a part of it. Agile, for example, creates a shared experience constructed around a shared vocabulary (‘scrum’, ‘sprint’, ‘grooming’ … etc), one that is reinforced by regular ceremonies that agile team members participate in. Just as agile creates this shared experience around the notion of change, a culture of engineering quality should create a shared experience around quality software development.


Much like how various cultures around the world use some variation of the Tea Ceremony to bring people together in shared contexts, Agile’s use of structured ceremonies provide a common cadence and framework for software engineering.

Last but not least, we can not leave the concept of Leadership out of this foundational perspective on engineering quality, nor other ‘soft’ issues such as how customers are included in the development process and how team-members are on-boarded.

Scope of this series

This, then, is the concept of ‘Culture of Engineering Quality’ that will be our guide star for this series of articles. Some pieces published in this series will seek to identify and explain the key roles, responsibilities, best practice and accountabilities that create the foundations of a culture of quality. Other articles in this series will look at some real-world examples of ceremonies that can be defined around that foundational set of standards, while still others will establish guidance around how all of these ideas can be assembled into a comprehensive approach to project governance. Some pieces will examine issues of leadership, while others will address softer issues such customer dynamics and integrating change into the flow of software projects.

What’s next

This series will start out with a look at how CI/CD/CT/CQ tooling, best practices, roles and responsibilities can be unified with the flow of source code management.

Tags: , , , ,