The quality pyramid in software development

Funtional Quality

If we think of ourselves as a black box delivering things outwards, functional quality is how the result of our work is perceived from the outside world. It doesn’t really matter how we did it, the product has to do what it was intended to do, and has to do it well.

This is the top of the pyramid and we will only reach it if we have a good foundation, ergo, we have a good structural and process quality.

Our main goal is to have a minimum amount of incidents perceived by the client. Our codebase might be really messy, our architecture could be all wrong, but if the client does not perceive any error, then we are meeting the functional quality just fine.

To meet our goals, we need

• To meet the specified requirements
  software does what it was required to do

• Few defects
  it does what it has to do without failing

• Good enough performance

• Ease of learning and ease of use
  great UX/UI

Structural Quality

Going back to the black box model, this time we are inside the box. That is, it is not what the client perceives of our work but rather the state of our code and tools. When we talk about structural quality we talk about the health state of our codebase.

We can say we have a good structural quality when we have a minimum amount of bad coding incidents, or, in other words, healthy code. We want to have an understandable, maintainable, scalable, effective, efficient and secure solution.

Summing up, to meet structural quality we need

• Code understandability
  code expresses intent: what it does and what for

• Code maintainability
  easy to change, low technical debt

• Code scalability

• Code effectiveness & efficiency
  does what it should and with good performance

• Code security
  secured sessions, sanitized inputs, encrypted data, etc.

Day after day, these are the enemies we fight

• Duplication
  always a bad idea

• Code Smells
  when it is not REALLY bad, but could be made better

• Churn
  too much refactoring in a short time

• Cognitive Complexity
  hard to read and understand

• Cyclomatic Complexity
  too much logic in one piece of code

Process Quality

The process is what we do every day to affect the value perceived by both end users and ourselves. We should think about this as each and every thing we do, not matter how big or small, in our everyday work. This is how we communicate, how we code, how we share knowledge and how we ask for help. This is why it is the base of the pyramid and why we must care so much about it. Every little disregard, every small task left undone, every poor piece of communication makes our project brittler.

What we seek to have is a repeatable development process that reliably delivers quality software while meeting delivery dates. Repeatable, reliable. Not just meeting the delivery date by chance, but knowingly taking steps towards a solution and trusting that we will be able to do that again.

To have a healthy process, we want to guarantee

• Tasks with clear requirements

• Single source of truth
  one issue tracker to rule them all

• Structured, continuous workflow
  not just getting there by chance

• Good communication
  both within and outside of the team

In order to get there, we do

• Scrum
  sprint planning, daily meetings, retrospectives

• Structured repository setup
  start with the right foot

• Code reviews
  we look after each other

• General good practices
  heal the code, make it a better place

Code Quality

In the next post of this series we will go one step deeper and mention some of the metrics we pay attention to and the tools and good practices we use in the never-ending quest for quality.