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.
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
it does what it has to do without failing
Good enough performance
Ease of learning and ease of use
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 expresses intent: what it does and what for
easy to change, low technical debt
Code effectiveness & efficiency
does what it should and with good performance
secured sessions, sanitized inputs, encrypted data, etc.
Day after day, these are the enemies we fight
always a bad idea
when it is not REALLY bad, but could be made better
too much refactoring in a short time
hard to read and understand
too much logic in one piece of code
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
both within and outside of the team
In order to get there, we do
sprint planning, daily meetings, retrospectives
Structured repository setup
start with the right foot
we look after each other
General good practices
heal the code, make it a better place
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.