What Does 'Quality' Really Mean in Software Development?

Have you ever pondered the nature of quality? If you have, you're not alone. In the realm of software development, the question of quality is both central and elusive. As Jerry Weinberg famously put it, "Quality is value to some person." But, while this statement is profound, it begs the question: how can a growing engineering team come to a shared understanding of what quality means to them?

Let's explore three methods small engineering teams can use to define and understand quality:

1. Determine Who Your "Some Person" Is.

The first step is to identify the 'some person' or persons Weinberg refers to. In the context of a startup or a small engineering team, this could be:

• The end-user or customer: What do they value? Is it speed? Intuitiveness? Reliability?

• The business or stakeholders: They might value scalability, maintainability, or features that open up new revenue streams.

• The developers themselves: They could value clean code, documentation, or ease of future updates.

Each perspective brings its own definition of quality, and acknowledging each can guide your team's focus.

2. Create Shared Quality Metrics.

To avoid the pitfalls of subjectivity, develop quantifiable metrics that reflect your team's understanding of quality. These can range from technical metrics (like performance benchmarks or error rates) to user-focused metrics (like net promoter scores or customer feedback).

However, remember that metrics should serve as a guideline, not a rulebook. They should be continually reviewed and adjusted as your product evolves and as you gather more feedback.

3. Foster a Culture of Open Feedback.

Defining quality isn’t a one-off task; it’s an ongoing conversation. Foster an environment where team members feel comfortable giving and receiving feedback about the product. Encourage regular retrospectives, where the team can discuss what went well and where improvements can be made.

By creating a safe space for open dialogue, you're not only sharpening your team's collective understanding of quality but also reinforcing a culture of continuous improvement.

In conclusion, defining quality is not about setting rigid standards or meeting certain benchmarks. Instead, it's about understanding the unique value your product brings to its users and stakeholders, and then ensuring every update, feature, or change enhances that value. By identifying your "some person", establishing shared metrics, and cultivating a culture of feedback, even small engineering teams can effectively define and maintain high-quality standards.