Quality Beyond “Working”

When you think of the term “Software Quality”, what comes to your mind.  Let me propose that how you think of quality depends heavily on your “relationship” to the software product.

If you are a user of that software product – quality relates to the following qualities in order:

1. Operational Correctness – It produces the expected results given the appropriate inputs.
2. Utility  – It adds value to me in support of specific job activities.
3. Efficiency – I am not required to complete steps that are not “relevant” to the outcome.
4. Performance – I don’t feel like each operation takes soooo long to finish.
5. Consistency – The way I interact with this software feels the same across the range of functions.

What about if you are a manager of the users of that software?

1. Low Training Requirements – software is implemented in a way that makes it easy for my staff to learn and use.  The consistency concept in the user definition certainly plays a role in this concept
2. Effectiveness – software is implement in a way that helps my staff increase their probability of success.  This goes to things like input validation and appropriate feedback mechanisms as well as business rules that reduce operational risk.

What about if you are the product owner or product manager of that software?

1. Sustainability – The software does not require frequent crisis mode remediation of issues.
2. Low Cost of Ownership – The operation of the software in production environments does not require a significant human input, either in responding to operational inquiries or end user frustrations (see items 1,4,5 in the user section)
3. Extensibility – Significant redesign is not frequently required to enhance or amend existing capabilities or add new capabilities.

What about if you are a developer of that software?

1. Consistency – The source code follows consistent patterns, design decisions adhere to well-understood industry practices, individual developers are not allowed to “diversify” the code base without it being the “intention” of the whole team to support that diversity.
2. Readability – Names of classes, variables, methods, properties etc. follow some semantics that relate to the problem domain that would resonate with users during a discussion.  Direct techniques and algorithms are preferred to “clever” or “opaque” methods – it should be obvious what is happening and how it is happening.  Evidence of unit testing should be visible and comprehensible.
3. Intentionality – Evidence of intentional design and disciplined review of code output – Whether this is included in the code base, or in the source code repository as documents or check-in commentary  – the intentionality of the team is a clear indicator of software quality.

This is my opinion.  I would love it if you would add your opinion from perspectives that you have inhabited about what makes a software product good.