The quality pyramid in software development

Relying on everyday processes to reach high standards

Sharing is caring!

by Martin Aliverti


When talking about quality there are different aspects worth noting, in order to understand better what to do, where and when. We will be focusing this post on software but the same principles stand for anything worth of quality assessment.

We can think of our overall quality as the result of the functional, structural and process aspects of quality. If we lay them one on top of the other, we will see that everything stands on the shoulders of a healthy daily process. Only by satisfying the lower levels of our pyramid will we be able to reach the uppermost level without shedding blood sweat and tears.

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.

Everybody’s been in a project that delivers functional quality while still having a less-than-perfect codebase, but at what cost? Most likely stress, working overtime and an overall bad feeling floating in the air. It is much easier to deliver functional quality when taking care of the lower levels of the pyramid.

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.

Code is always written with a purpose, but sometimes it’s not clear in the code itself. We need to write code that expresses intent, not just what it does but also what for.

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.

Related post: How to Estimate Custom Software Development Pricing

More articles to read

Previous blog post



Defining quality in software development

Read the complete article

Next blog post



Code Quality I: Good Practices

Read the complete article