Chapter 5. - Productception
📦

Chapter 5. - Productception

Users & Development —

What will you learn here?

  • What's product quality and how to look at software as a product.
  • A new system to discuss software quality.
  • How to connect technical quality attributes to product quality.

Introducing Product Quality

Because software is a product and one of our main goals is to make it a successful one, it's crucial to understand how products work in general. This is the basis for having a "product sense" which I sometimes see as a requirement in software engineer job postings. If you ever wondered what does that exactly mean you will find the answer here. The ability to see through the eyes of the buyers (not users) of our product is something we are severely lacking. The key is to answer two questions:
  • What are the general properties of successful products that make them desirable?
  • What makes you want to buy something again and again?
After much trouble I identified 15 properties as my answer. I call them the:
Attractors: The product quality attributes that can convince people to purchase something.
If you can tell the effects of a tech decision over these factors you will be able to make effective choices from the customers' perspective. I found that it's much more practical to speak about the attractors not in terms of importance - of course all of them are important - but in terms of tolerance. How much a software product can afford to lose on a quality attribute without affecting its chances of success too much. I will detail how the business domain affects the level of tolerance over the different elements of product quality. I also list the related software quality attributes in advance. We will discuss them later separately.

1. Easy to access

Description: You can get it with the least possible effort and waiting. Compare grabbing a sandwich from the selves in a store to buying an authentically made exotic food in the only restaurant that offers it in your country, far away from where you live. Ease of access is often the preferred alternative. On the other hand is the tradeoff between this property and security. It's much easier to grab your gold savings from a drawer at home than from a high security bank's safe but the convenience sometimes doesn't worth it.
Translated to software: This spans many dimensions. The most dominant is UX design. Intuitive UIs and workflows enable accessing product features easily, that means good Findability. Learnability is also key. On a different level anything that has influence over how easily new users can find, install and update the product also belongs to this category. SEO, legal and platform compliance are the main factors but eliminating any kind of barrier is related. Like supporting as many languages or payment options as possible. Even marketing and community building efforts count here as they increase the visibility of the product.
Tolerance: This scales in reverse with the number of people who are going to use the solution and the level of competition on the market for them. Internal tools for an organization, embedded programs or projects developed for a long-time, exclusive customer are all low risk examples. Anything highly competitive demands top performance in ease of access.
Show related SQAs
  • Accessibility: User: In this context accessibility is sometimes the enabling factor to use the product. How well it is done determines ease of access for them.
  • Security: User: This can hinder ease of access with tedious workflows and slower processing speeds. Legal: Security can also be an access enabling factor if platform or legal regulations require meeting certain levels in order to approved.

2. Low cost

Description: Some people prefer a low price over many other properties. It's important to take the whole product lifecycle into account, (acquisition, operation, maintenance, decommission) not just the initial price of purchase/creation. It involves accounting for things like resource usage, maintenance, insurance, compliance or the costs of removing it. In the best case the product seems so cheap it feels like a waste not to buy it.
Translated to software:
Tolerance:
Show related SQAs

3. High performance

Description: The product can perform its intended functionality with high effectiveness and efficiency.
Translated to software:
Tolerance:
Show related SQAs

4. Luxurious

Description: Products that offer social benefits like prestige or recognition usually through only being affordable by high status individuals.
Translated to software:
Tolerance:
Show related SQAs

5. Pleasant to use

Description: Creates a positive experience, easy to learn, intuitive to control.
Translated to software:
Tolerance:
Show related SQAs

6. Professional customer service

Description: It's a transitive product property. On the first level this is an attribute of the company selling/supporting the goods, covering all the parts of the CL that include human contact between the customer and the company. (Including: sales, helpdesk, guarantee, repairing, replacing, etc...) However it gets associated with the product very fast. Have you not ever choose one meal over another just because the staff was much more/less professional at a certain place?
Translated to software:
Tolerance:
Show related SQAs

7. Effective visual design

Description: It looks appealing, matches the customer's taste, triggers the right emotional responses, distinctive, practical.
Translated to software:
Tolerance:
Show related SQAs

8. Easy to maintain

Description: Low maintenance needs, easy to repair, supplies and replacement parts are available and affordable, help is easy to find and of high quality.
Translated to software: Most developers are experienced with maintaining code but what does it mean for software? From a customer perspective the main concern is receiving updates. It counts as maintenance when the update delivers quality of life improvements, bugfixes or performance optimizations. How frequently they arrive and how well they meet the real user needs are two main factors of customer satisfaction in the maintenance regard. Another component of this area is inspectability and modifiability by the end user. When the software enables them to produce improvements for their problems by offering plug-in, extension or modding capabilities or even deeper tweaking of the underlying system the software has better maintainability in a product sense. The same goes for tools that enable diagnosing internal technical problems by the users.
Tolerance:
Show related SQAs

9. Price to value ratio

Description: For conscious buyers the choices often come down to getting the most bang for their buck.
Translated to software:
Tolerance:
Show related SQAs

10. Reputation

Description: The product is widely known to be the go-to solution when facing a certain problem. It's made by a well known and trusted creator, be it a company, team or an individual.
Translated to software:
Tolerance:
Show related SQAs

11. Feature match

Description: It doesn't offer more or less functionality than you need. It's the right tool for the job. This might be the most trivial factor. You likely wouldn't buy a Swiss army knife when all you want is to tighten a screw. Nor buying shorts for an arctic expedition.
Translated to software:
Tolerance:
Show related SQAs
  • Accessibility: User: For disabled persons, accessibility is a feature in and of itself.

12. Customizable

Description: You can choose some or all of the functional or visual components of the product to fit your preferences. It might support customization only by the manufacturer, licensed third parties, or the owners themselves. It might be possible before and/or after the product is made. It can be extended to involve upgradability if that's considered as a kind of customization.
Translated to software:
Tolerance:
Show related SQAs

13. Low environmental impact

Description: The product doesn't affect its environment - living or inanimate objects or on an abstract level the surrounding processes - in harmful ways, above the acceptable levels. I use it as an umbrella term covering a lot of different factors like the ecological impact, the safety of people and objects, the performance of related processes or the level of regulatory compliance.
Translated to software:
Tolerance:
Show related SQAs

14. Compatible

Description: The product can be used with or by the other tools you choose.
Translated to software:
Tolerance:
Show related SQAs

15. Reliable

Description: The product is operational, up to the expected level in every circumstance it meant to be used in. Some important components of reliability are adaptability, observability, durability, fault tolerance, provided backup parts and much more depending on the product type.
Translated to software:
Tolerance:
Show related SQAs

Summary

These are the elementary attractors. Virtually all of us are familiar with using them when making a purchase decision. To put this in the context of what we already learned these are the main factors in the evaluation phase of CL and they heavily affect experience and bonding too. Going further these also categorize the buyers into market segments because with different personalities, financial and life situations comes a well defined set of preferences over these 15 dimensions. So it can be used in two ways. To identify, on a high level, what kind of software we want to create if we know our target audience, or to target and engage the right audience if we already know the properties of our product. This is useful for us because the User API can be more or less mapped to the attractors and by that we can broadly tell what will be the market perception of our work.

A note on high quality

I purposefully left out quality from the list of attractors. What it actually means depends on the product type and price range. High quality safety helmets are offering great protection, but might look very bulky. High quality running shoes boost performance but might not last long. Because of this relativistic nature it's not an actionable attribute. The most fitting definition for high quality I could come up with shows this nicely:
A product has high quality when it can meet or exceed the high expectations of its users.
It's the only definition that's applicable over every product category and price range. As high quality always depends on user expectations it always is a selection of the other elementary attractors that are considered the most important for a product type in general.

Introducing Software Quality Attributes

This is a very important part of bridging the gap in the relationship between business outcomes and tech decisions. Many of the financially relevant effects we can produce manifest through the quality of the software we create. If you can map technology properties to SQAs on your project, you can easily evaluate how they affect CX and related business outcomes. I will do that in Chapter 12. My favorite thing about SQAs is their timeless and technology independent nature. They are describing software based on its fundamental characteristics which doesn't depend on the tools we use to create it. This is universal knowledge, relevant until we die or software transforms into something extraterrestrial.
I will show you two approaches that we will build upon. The first is the ISO/IEC 25010:2011 software quality standard which defines 8 main quality characteristics each containing a total of 31 sub-characteristics. And the Wikipedia list of System Quality Attributes listing 84 characteristics. These are wider in scope than the ISO standard, taking entire software systems into consideration. This is an area where software engineers reign supreme in delivering business value. No other profession can influence the realization of these significant factors. That's why I believe this should be one of the main concerns of full context developers. If we want to focus on delivering value it's an important tool in guiding discussions and decisions.
The lists coming are a lot to take in at once. Don't try to do that. Start by taking an overview. Get a feel for the general themes. You are free to dive into details, but for me it was an overwhelming amount of information to process. I suggest to go on with the chapter and the book and get back to here as you encounter related topics and want to know more.
On a side note, I realized these sources don't use the software-code duality. That means there are properties involved that are purely code related, which in turn means they have 0 direct relevance to the product qualities. Their only real concern is the productivity of the developers which in turn has CX consequences but nothing directly affecting the quality of an already delivered product. This is one of the reasons why it's practical to use this distinction. How code affects the users will be detailed in Chapter 11. - The Final Quest of Programming.

ISO Standard

We will use these categories to construct our own high level groups of SQAs. They will often be sufficient and very helpful in discussing product quality implications. (I'm omitting the sub-items of the standard, we will fill them our way later.)
  • Functional suitability: How well does the system meet the needs of the users. In plain, how well does it solve their problems. This is of course the basic quality aspect, but this is mostly non-technical, except in the ways we already discussed.
  • Performance efficiency: How suitable is the system to provide high levels of Usability during user interactions. In plain, the software is fast and stable enough while utilizing acceptable level of resources.
  • Compatibility: The ease of integration with other IT systems it's expected to communicate with or share resources with and the level of detrimental impact the systems have on each other.
  • Usability: The standard defines it in a weird way if interpreted from the perspective we used so far. It uses the same trio of efficiency, effectiveness and satisfaction as we did, but extends them with subcategories that cover learnability, findability and desirability, so nearly all UX concerns, yet it's not called that but only a subcategory if it.
  • Reliability: The percentage of time the software can fulfill its intended purpose vs not.
  • Security: How well does the software enforce the information and data access restrictions of users and other systems.
  • Maintainability: This is again a confusing property as maintainability is not an attribute of software but of code. This is a concern for the developers who are interacting with it. It measures of how easy it is to modify the code to fix issues, change existing behavior or deliver new functionality.
  • Portability: This is also a confusing category as this is again a property of code, how easy it is to port it into other environments than it's original.
My critique of the standard: If you think about it, many top level properties defined by the standard can influence the efficiency of using a product (performance, reliability) which is a factor in Usability. This way the properties don't seem to be well isolated, separate concerns but a weird mix of UX elements and technical properties somehow elevated to the same level. The inclusion of code related metrics is also confusing from our perspective.

The Full Context Software Quality System

I will use a new categorization to group SQAs together, called software quality families. I found it much more logical and practical to flip the perspective around and instead of looking at the software/code look at those who are interacting with it. This view leads to a more well separated list of concerns. These are broader in scope than the related ISO categories but I will show them for reference. I apply the software - code duality view here, so no purely code related attributes are involved. Here are the different quality families:

User Quality

In interaction with: - The humans using the software
Measures: CX measures
ISO: Functionality, Usability, Performance, Reliability, Security

Developer Quality

In interaction with: - The humans working on the software
Measures: Productivity and Utilization measures
ISO: Maintainability, Portability to some extent

Operator Quality

In interaction with: - The humans operating and supporting the software
Measures: Support activity related measures. (eg: MTTR)
ISO: Maintainability and Portability sub items (Analyzability, Installability)

Legal Quality

In interaction with: Laws and Regulations
Measures: Compliance and conformance measures
ISO: Security

Environment Quality

In interaction with: The human and non-human environment of the system
Measures: Safety and other interaction measures
ISO: N/A

System Quality

In interaction with: Other software systems / applications
Measures: System interaction measures
ISO: Compatibility

Platform Quality

In interaction with: IT platforms delivering and operating the product
Measures: Platform interaction measures
ISO: Portability

How to think in quality families?

Instead of defining and measuring quality in the level of compatibility, maintainability, performance, etc... the software has, I propose to talk about software quality in terms of its user/operator/platform/etc... quality. I first thought these might be harder to use than the ISO categories, but those aren't exact, directly measurable properties either. They are categories just as these. The sub items are what matter in practice, however this new categorization has one huge benefit over the standard. It groups SQAs together by their outcomes on the Financial API. Business effects surface through the software's interaction with its environment. This is like a model of that environment. Thinking in these categories also help in shifting our focus from the technical details to the outcomes which is a huge win in itself. So performant software with high levels of usability is said to be high user quality software in this system. This feels strange and off at first but it's easy to adopt to.
TODO: Remove Code Quality Attributes from this list.

System Quality Attributes

accessibility
Description: The classical meaning of accessibility is the software's ease of use by disabled or impaired persons. In UX terms I like to extend its meaning with affordability but from a technical perspective they are separate concerns. This can be a legally required property to provide.
Family: User, Legal
Related attractors:
Easy to access
Pleasant to use
Feature match
Compatible
accountability
Description:
Family:
Related attractors:
accuracy
Description:
Family:
Related attractors:
adaptability
Description:
Family:
Related attractors:
administrability
Description:
Family:
Related attractors:
affordability
Description:
Family:
Related attractors:
agility
Description:
Family:
Related attractors:
auditability
Description:
Family:
Related attractors:
autonomy
Description:
Family:
Related attractors:
availability
Description:
Family:
Related attractors:
compatibility
Description:
Family:
Related attractors:
composability
Description:
Family:
Related attractors:
configurability
Description:
Family:
Related attractors:
correctness
Description:
Family:
Related attractors:
credibility
Description:
Family:
Related attractors:
customizability
Description:
Family:
Related attractors:
debuggability
Description:
Family:
Related attractors:
degradability
Description:
Family:
Related attractors:
determinability
Description:
Family:
Related attractors:
demonstrability
Description:
Family:
Related attractors:
dependability
Description:
Family:
Related attractors:
deployability
Description:
Family:
Related attractors:
discoverability
Description:
Family:
Related attractors:
distributability
Description:
Family:
Related attractors:
durability
Description:
Family:
Related attractors:
effectiveness
Description:
Family:
Related attractors:
efficiency
Description:
Family:
Related attractors:
evolvability
Description:
Family:
Related attractors:
extensibility
Description:
Family:
Related attractors:
failure transparency
Description:
Family:
Related attractors:
fault-tolerance
Description:
Family:
Related attractors:
fidelity
Description:
Family:
Related attractors:
flexibility
Description:
Family:
Related attractors:
inspectability
Description:
Family:
Related attractors:
installability
Description:
Family:
Related attractors:
integrity
Description:
Family:
Related attractors:
interchangeability
Description:
Family:
Related attractors:
interoperability
Description:
Family:
Related attractors:
learnability
Description:
Family:
Related attractors:
localizability
Description:
Family:
Related attractors:
maintainability
Description:
Family:
Related attractors:
manageability
Description:
Family:
Related attractors:
mobility
Description:
Family:
Related attractors:
modifiability
Description:
Family:
Related attractors:
modularity
Description:
Family:
Related attractors:
observability
Description:
Family:
Related attractors:
operability
Description:
Family:
Related attractors:
orthogonality
Description:
Family:
Related attractors:
portability
Description:
Family:
Related attractors:
precision
Description:
Family:
Related attractors:
predictability
Description:
Family:
Related attractors:
process capabilities
Description:
Family:
Related attractors:
producibility
Description:
Family:
Related attractors:
provability
Description:
Family:
Related attractors:
recoverability
Description:
Family:
Related attractors:
relevance
Description:
Family:
Related attractors:
reliability
Description:
Family:
Related attractors:
repeatability
Description:
Family:
Related attractors:
reproducibility
Description:
Family:
Related attractors:
resilience
Description:
Family:
Related attractors:
responsiveness
Description:
Family:
Related attractors:
reusability
Description:
Family:
Related attractors:
robustness
Description:
Family:
Related attractors:
safety
Description:
Family:
Related attractors:
scalability
Description:
Family:
Related attractors:
seamlessness
Description:
Family:
Related attractors:
self-sustainability
Description:
Family:
Related attractors:
serviceability
Description:
Family:
Related attractors:
securability
Description:
Family:
Related attractors:
simplicity
Description:
Family:
Related attractors:
stability
Description:
Family:
Related attractors:
standards compliance
Description:
Family:
Related attractors:
survivability
Description:
Family:
Related attractors:
sustainability
Description:
Family:
Related attractors:
tailorability
Description:
Family:
Related attractors:
testability
Description:
Family:
Related attractors:
timeliness
Description:
Family:
Related attractors:
traceability
Description:
Family:
Related attractors:
transparency
Description:
Family:
Related attractors:
ubiquity
Description:
Family:
Related attractors:
understandability
Description:
Family:
Related attractors:
upgradability
Description:
Family:
Related attractors:
usability
Description:
Family:
Related attractors:
vulnerability
Description:
Family:
Related attractors:

How did you like this chapter?