
# How redefining Software Quality can save your day?


## Do we have to introduce software quality yet?

In recent years many teams have adopted QA thanks to plug & play affordable [CI/CD](https://en.wikipedia.org/wiki/CI/CD) solutions. It's almost a convenience now. Also [DevOps](https://en.wikipedia.org/wiki/DevOps) then [DevSecOps](https://en.wikipedia.org/wiki/DevOps#DevSecOps,_Shifting_Security_Left) have contributed to have Quality as a culture as everybody's became a stakeholder! I bet next gen developers could be qualified as "quality natives".

However, when I search on internet, I'm disappointed because I mainly find:

  1. High level standard definitions (ISO 🌐, please certify me 💵)
  2. [Quality Assurance](https://en.wikipedia.org/wiki/Quality_assurance) (QA) resources (a lot of noise 🤯)

Come on guys:
- Few teams only are (or will get) ISO certified.
- With QA, most people use tools that help achieving a goal, but don't deeply understand why they use them.

And this is the problem : quality is more a mantra than a tool that you plug or just processes. That's what we will see. So yes, let's re-introduce software quality!  🎉

💡 In later articles of this series, we will also see how we distillate quality from a pragmatic point of view 💯.

## Is software quality a necessity?

In the early years of computer science - in 1968 - a ["Software crisis"](https://en.wikipedia.org/wiki/Software_crisis) happened. The cause was the difficulty of writing useful and efficient computer programs in the required time. Low quality was one of identified symptoms.

> Low quality is like pollution paradox: even polluters don't like to pollute.

But let's go back to our day to day reality. During last 20 years I've seen teams that were delivering a quality level but where not even conscious of this level. Time and budget were the most preponderant factors to deliver software and quality was a third party one. And sometimes it was even considered harmful for (or not included in) time and budget. Maybe because quality is seen by many as a sacred concept, a quest of the absolute.


This is why I think that software quality is a necessity... but team members - please de-sacralize quality 🙏. Here's a simple tip on how to do that:

> **Get agree on a definition** of what software quality is and what it implies in **the current team context.**


## Our team definition of Software Quality

First of all, I want to give you our context:

1. We're a small team of up to 5 developers, each of them with 5 to 20 years of professional experience;
2. working in a small to medium company (less than 20 employees);
3. specialized in hospitality industry:
   - many business units involved;
   - a lot of workflow and automation topics.

So the following definition makes explicit every concept beloved by our team:

> Software Quality represents all the processes and measurements that people can put in place to ensure expectations in an appropriate and continuous improvement mindset.

To sum up, 7 key concepts that we've decided to own in the team:

<img src="/assets/blog/how-redefining-software-quality-can-save-your-day/gogaille-software-quality-key-concepts.png" alt="Gogaille tech team: 7 software quality key concepts" width="664" height="385" />

The only thing that we don't define very well are expectations, as we believe it's a kind of alchemy between domain and software experts.

As this definition is personal, your team will need to have its own definition too. So, I can explain you how did we get there.


## Our sources of inspiration

### ISO

Up to 2011, [ISO 9126](https://en.wikipedia.org/wiki/ISO/IEC_9126) definition was:
> Capability of a software product to conform to requirements.

No comment, very synthetic, not so useful. But wait, since that [ISO 25010](https://iso25000.com/index.php/en/iso-25000-standards/iso-25010) has refined the definition 🎉:

> The quality of a system is the degree to which the system satisfies the stated and implied needs of its various stakeholders, and thus provides value. Those stakeholders' needs (functionality, performance, security, maintainability, etc.) are precisely what is represented in the quality model, which categorizes the product quality into characteristics and sub-characteristics.

More exhaustive... but very theoretic and small to medium teams that will not get certified at any time in their life will probably never cover all parts, they have to choose their battles. Anyway, the quality model is here to help us:

<a href="/assets/blog/how-redefining-software-quality-can-save-your-day/iso25010-quality-model.png">
  <img src="/assets/blog/how-redefining-software-quality-can-save-your-day/iso25010-quality-model.png" alt="ISO 25010 quality model" width="1521" height="430" />
</a>

### Other industries than software

Hey, don't forget that quality processes in software are vastly inspired from older industries because of the precedence of the former and the fact they have in common to be production/delivery oriented.

#### 1986 - Six Sigma

[Introduced by Bill Smith at Motorola](https://en.wikipedia.org/wiki/Six_Sigma), Six Sigma qualifies processes that lead to a 99.99966% free of defects production.

<img className="floating-right w-24" src="/assets/blog/how-redefining-software-quality-can-save-your-day/om_droit_au_but.png" alt="Olympique de Marseille soccer team baseline" width="1200" height="1525" />

We've retained that quality is a question of **continuous measurement** on one side and **clearly defined goals** on the other side. It's straight to the point. As I live in ⚽ Olympique de Marseille soccer team's city I appreciate a lot.

#### 2001 - The Toyota Way

This is [a set of 14 principles](https://en.wikipedia.org/wiki/The_Toyota_Way). It focuses on 2 key areas:

1. continuous improvement → incremental, never ending;
2. respect for people → great people produces great value.

Worth to mention that Toyota became the world's number one car maker in 2007 and remains in top 3 since that time 😉. Here's my personal curation of things that make a lot of sense across the 14 principles:
- Long-term philosophy: people need a purpose to find motivation and establish goals.
- The right process will produce the right results:
  - eliminate wastes (7 identified types);
  - build a culture of stopping to fix problems, to get quality right the first time.

So here we learn that **long-term** and **culture** are key regarding quality. And of course - not a surprise - **people** and their implication is crucial!


## What's next?

As we now have a good definition of quality, we can start our journey with confidence. Please be certain that your quality definition is a dynamic concept so it's a good thing to redefine it through your milestones.

In next posts I want to talk about many subjects, among:

1. When should I bother about quality?
2. How to build a culture of quality?
2. How to rollout quality?

And what about you? 🤔 Please share your context and give back your own definition. You can also suggest topics for following posts I'll try to cover them.


How redefining Software Quality can save your day?


Après 1 an, la tête dans le guidon, il était temps de ralentir un peu et prendre le temps de partager sur l'aventure qui a rassemblé une partie de l'ancienne équipe tech de VeryLastRoom :

- [Sébastien Houzé](https://twitter.com/sebastienhouze) : CTO à tout (bien) faire
- [Armand Abric](https://twitter.com/armandabric) : Fullstack affinité js
- et moi-même, [Timothée Barray](https://twitter.com/timbarray) : Backend développeur, bidouilleur de js

Et 2 nouvelles recrues bientôt ! On a hâte !

# Contexte

Début 2020 (avant covid and co) nous signons tous les 3 pour rejoindre une entreprise bordelaise : [French Hospitality](https://french-hospitality.fr).

Notre mission ? Repartir de zéro pour (re)produire tout le SI d'une chaîne d'hôtel avec la volonté depuis le début de pouvoir automatiser et basculer dans le numérique la plus grande majorité des process d'un métier qui a encore du mal à sauter le pas du 21e siècle.

Loin de nous l'idée de réinventer la roue par contre ! Aujourd'hui il existe un grand nombre de logiciels pour réaliser une bonne partie de ce travail.

Mais l'idée de pouvoir tout rationaliser dans un seul endroit et éviter le syndrome du multi backoffice nous semblait importante dans notre quête d'optimisation.

De l’autre côté, on pouvait alors s’attacher à découvrir ce domaine métier et modéliser avec le plus grand soin l’aspect différenciant de notre concept.

[Gogaille](https://www.gogaille.com/) était né.

# De quoi ça s'agit ?

Nous sommes tous les 3 très attachés à la notion de partage et nous avons été heureux de pouvoir contribuer au cours de l’année à différents logiciels que nous utilisons dans nos applications, comme [Bref](https://bref.sh/), [AsyncAws](https://async-aws.com/) ou même [Symfony](https://symfony.com/). Mais on s'est vite dit qu'on aimerait apporter plus encore et l'idée d'un blog nous trottait dans la tête depuis un moment.

Nous allons donc partager ici ce qui nous passionne ou nous anime selon nos envies.

Les sujets tourneront forcément autour de notre pile logicielle, de nos expérimentations et des défis qu’on doit relever.

<img src="/assets/blog/intro/lego.jpg" alt="Construction de légo" width="1920" height="1280" />

## Briques logicielles

Histoire de vous donner un avant goût, on peut vous présenter un peu l’application comme elle est aujourd’hui après 1000 commits (et à peu près autant de pull requests pour vous donner une idée).

Toutes nos briques applicatives sont regroupées dans un [monorepo](https://github.com/korfuri/awesome-monorepo) sur Github. Que des avantages et on est loin d’avoir une taille qui pourrait poser problème.

On pourra parler un peu de chacune de ces briques dans un billet dédié (si ça vous intéresse dites le nous) mais dans les grandes lignes :

### API Rest

Elle est en PHP 8 avec Symfony 5. C’était la solution qu’on maitrise le plus et dont on est globalement satisfait.

On utilise [Api-Platform](https://api-platform.com/) pour la couche REST mais sans doctrine (ni aucune base de données relationnelle). C’était ici notre première expérience. Et après un petit bench en début de projet on s’est dit que ça pouvait valoir le coup.

On va pas se mentir, on a un peu bataillé, sortant du cadre défini de APIP (ni doctrine ni crud), mais on a aujourd’hui quelque chose de fonctionnel et qui nous apporte une plus value. Est-ce qu’on va le garder à terme ? La concurrence étant maigre, la seule alternative serait de le coder… Wait and see.

L’application en elle même est structurée selon les principes du Monolithe Modulaire. J’ai donné [une conférence au Symfony Live 2020](https://symfonycasts.com/screencast/paris2020/monolithe-modulaire-pourquoi-comment) si le sujet vous intéresse. On en reparlera certainement ici aussi ;)

Pour la partie Serverless, on utilise l'incontournable Bref. Merci [Matthieu](https://twitter.com/matthieunapoli) pour cette superbe librairie !

### Client Web

Côté client, pas de surprise on utilise React mais avec du Typescript qui apporte un vrai confort grâce à son système de Typage. Le tout géré par [Next.js](https://nextjs.org) pour avoir un cadre de travail agréable.

On utilise [Vercel](https://vercel.com) pour l’hébergement. Je laisserai le soin à Armand d’en parler plus longuement dans un prochain billet moi je fais que bidouiller cette partie :D

### Client “lourd”

À destination de tablette pour prendre place dans les halls de nos hôtels en tant que borne de réservation. C’est en fait aussi un client web (propulsé par [create-react-app](https://create-react-app.dev)) mais avec une interface adaptée aux spécificités du medium : espace publique (session courte) et écran tactile. Au stade de prototype pour l’instant.

### Un CMS Headless

Toujours dans un souci de ne coder que les choses importantes, on a délégué toute la gestion CRUD (et il fait même beaucoup plus) à un CMS Headless : [Sanity.io](https://www.sanity.io/).

Un vrai bijou, ce fut la très bonne surprise de nos expérimentations.

On l’a éprouvé de longs mois et il coche toutes les cases pour devenir le backoffice de la partie “Contenu” de nos systèmes.

### Une application Zendesk

Même principe. On ne veut surtout pas produire et maintenir un backoffice dans son ensemble. On a pas l’équipe pour et la plus value n'est de toute façon pas justifiée à notre sens.

On utilise donc [Zendesk](https://www.zendesk.fr/) comme outil de support avec une première application custom qui permet d'interagir avec notre API sans quitter Zendesk. Typiquement : Pour annuler la réservation d’un client.

<img src="/assets/blog/intro/rocket.jpg" alt="Lancement de fusée en légo" width="1920" height="1285" />

## Infrastructure

Côté serveur, on en a pas… On utilise AWS et massivement du Serverless. Pourquoi ? Parce qu’on est aujourd’hui que 3, et passer du temps à s’occuper des serveurs ne nous semblait pas optimal dans un premier temps.  
Pour information on avait démarré avec des images Docker déployées sur [ECS](https://aws.amazon.com/ecs). C'était dommage d'avoir autant de services qui tournaient 24/7 surtout pour une pré-production.
Et la promesse du Serverless a finalement été plutôt remplie pour nos besoins.

> C'était dommage d'avoir autant de services qui tournaient 24/7 surtout pour une pré-production.

Côté base de données, on utilise aujourd’hui principalement du [DynamoDb](https://aws.amazon.com/dynamodb). Et on se sert de notre CMS comme stockage de certaines données qui demandent à être pilotées via un CRUD. Typiquement nos catégories de chambres.

Pour le messaging, [SQS](https://aws.amazon.com/sqs) coche toutes les cases pour l’instant.

Par contre, on utilise [terraform](https://www.terraform.io/) pour facilement provisionner tout ça. On a payé le prix au début du projet mais aujourd’hui force est de constater que tout roule.  
Le grand plus ? Avoir dans la pull request un aperçu en mode "diff" de ce qui va changer sur l'infrastructure lorsqu'on va merger et donc de faire de la revue d'infra au même endroit que la revue de code.

## Workflow

Qui dit Github, dit [Github Actions](https://github.com/features/actions) dont on est également ravi. On s’en sert pour lancer les suites de tests de chacune de nos applis et on a réussi aujourd’hui à optimiser cette partie pour ne lancer que les tests propres à la PR en cours. Un des défis quand on utilise un monorepo.

Après le merge, tout ça part en prod directement. Via terraform et Vercel.

Évidemment, chaque PR doit être relue par une personne pour être mergeable. On utilise d'ailleurs depuis récemment l'auto merge de github qui fait le travail. D'ailleurs on utilise aussi la stratégie `Squash And Merge` par défaut, et qui permet de produire un historique vraiment propre.

Côté organisation, on est sur des sprints de 2 semaines avec des points démo avec toute l'équipe. N'étant pas encore en prod "réelle" on s'attache tout de même à s'occuper de notre preprod comme une vrai prod en la gardant 100% fonctionnelle pour que chacun puisse l'utiliser à tout moment.

<img src="/assets/blog/intro/way.jpg" alt="Panneau indiquant This way" width="1920" height="1280" />

## La suite

N'attendez pas un article par semaine, mais l'idée est quand même de faire quelque chose de régulier. 1 par mois serait déjà une réussite.

On essaiera de varier les sujets techniques et ceux plus méta et si possible qui vous intéressent. Alors n'hésitez pas à laisser des commentaires ou nous interpeler sur twitter.

Attendez vous à du contenu en français et en anglais. Chacun est libre dans l'équipe de contribuer dans la langue qui lui convient.

À très vite !


Build Gogaille.

We redefine the Hospitality world with the latest tech.

How redefining Software Quality can save your day?

More Stories

Soyez les bienvenus