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.