CHRYSOCODE

Nous sommes convaincus qu'un logiciel pensé pour être utile doit aussi être un produit fiable et bien construit, conçu pour absorber le changement continuellement, pour être livré à volonté en toute sérénité, pour durer sans douleur tant qu'il rencontre sa cible.

Pourquoi faire appel à nous ?

Chrysocode a pour mission de changer et d'améliorer...
- la flexibilité de vos organisations et logiciels,
- les délais de mise sur le marché de vos produits,
- la qualité perçue par vos utilisateurs.

Chrysocode est un cabinet de conseil spécialisé en stratégie IT et dans la conduite du changement en ingénierie logicielle.
Son ambition est de rendre à l'Ingénierie du Code ses lettres de noblesse, en libérant les potentiels humains et les savoir-faire. Entre Software Craftsmanship, Gears Of Software Testing (GOST™) et Clean Test®, découvrez notre offre.

Mobirise

Credo de Chrysocode

La conception logicielle ne se limite pas à prendre des décisions. C'est aussi savoir écouter l'impérieuse nécessité de changer la structure du code quand survient le besoin auquel répondre.

Tendre vers la meilleure décision de conception, c'est trouver les moyens d'attendre le plus longtemps possible avant qu'il ne soit trop tard.

En Informatique, toute chose temporaire devient définitive à l'instant même où elle existe. C'est encore plus vrai dans le code source.

Tout élément structurant de conception est associé à la fois à un gain et à un coût : le gain doit être supérieur au coût dans le temps. Sinon il faut y renoncer au plus tôt.

C'est dans le code source qu'émergent des conceptions d'excellence. Car elles naissent de la confrontation de préoccupations contraires. Ce sont les fruits d’accidents calculés.

Privilégier un couplage lâche et une cohésion forte, ce n'est pas vouloir les réunir à tout prix au même endroit. C'est faire le choix d'un couplage lâche entre deux composants à la cohésion faible, ou bien celui d'un couplage fort entre composants à la cohésion forte. Le reste n'est qu'une dette technique de plus.

Sphères Logicielles
Visez l'Essentiel(le).

Les défauts ne sont que la partie émergée d'un iceberg qui flotte avec la dette logicielle, qu'elle soit technique, organisationnelle, émotionnelle ou humaine. Et plus de dette signifie plus de défauts dans l'immédiat, et bien plus encore pour plus tard.

Une mauvaise conception ressemble à l'absence de conception : au lieu de faciliter les développements, elles les freinent, et les défauts adorent s'y nicher.


Allégorie de l'icebert : défauts vs dette technique
Corriger les défauts n'empêche pas le naufrage.

La programmation consiste à prendre en permanence de petites décisions qui auront de grands impacts. Une spécification formalise de grandes décisions qui ont de faibles impacts, sinon négatifs. En effet, la spécification, c’est le plan, alors que la programmation, c’est la planification. Une spécification a donc d’autant plus d’intérêt qu’elle se confond avec la programmation. D’où les développements pilotés par les tests.

En conception dirigée par les tests, on arrive à une conception comme on suit le chemin des tests. Si le chemin est hasardeux, la conception est une falaise. Si le chemin est astucieux, la conception est une plaine. En cela, un bon développeur est un paysagiste du code.

Qu'il s'agisse de conception ou d'anomalie, chacune a ses tests : on cueille la première, alors qu'on chasse la seconde.

Carte de métro des tests

Une bonne façon de ne pas se tromper de test est souvent de faire appel à deux personnes distinctes. Il en existe aussi une meilleure, sans exclusion mutuelle : concevoir le test avant le code.

Quand les tests de non-régression sont automatisés, on ne met pas les testeurs au chômage technique : on les laisse enfin exercer leur métier.

Quand les tests spécifient et documentent un logiciel, leur pendant n’est plus la spécification, mais la supervision, jusqu’à l’obsession de la mesure.

What else than Test-Last?

Les organisations sont des plans de culture à différents termes : on y récolte ce que l'on sème, même si les planteurs ne sont pas les cueilleurs, et leur avenir se dessine en fonction des récoltes à venir. Il faut pouvoir attendre pour récolter, et si rien n'a été planté pour une époque, tantôt proche tantôt lointaine, l'avenir en est compromis avec la même assurance.

Un centre de coût compte ses charges et réduit ses coûts. Un centre de profit bénéficie d’investissements et crée de la valeur. Il en va de même dans la façon de penser et de conduire la production de n'importe quel logiciel.

Les mêmes réflexes sont à l'œuvre qu'il faille communiquer au sein d'une organisation ou concevoir un logiciel. D'une part, les forces ou faiblesses existent en miroir. D'autre part, il faut changer de système de pensées pour espérer changer une faiblesse en une force.

Les organisations qui vivent leurs valeurs les transmettent par le geste, et non par le verbe. Les organisations qui communiquent le plus au sujet de leurs valeurs sont les mêmes qui en ont le moins. À trop parler d'une chose, on se persuade qu’elle existe, on en oublie qu'elle n'existe pas, et l'on fait de la propagande au lieu de communiquer.

N’importe quel être soucieux de son avenir prend soin de son patrimoine. Plus tôt une organisation prend conscience que sa richesse est humaine et que son patrimoine est logiciel, moins elle perdra de temps à dénigrer ses forces vives ou à incendier son code source.

La qualité des logiciels trouve son équilibre naturel entre l'expérience des utilisateurs et celle des développeurs : elles grandissent ou s'amenuisent ensemble. Et elles ne sont jamais déficitaires séparément.

Mobirise
Le Code source comme Acte culturel.

Il est facile de renoncer à la valeur en se focalisant sur la quantité plutôt que la qualité, en livrant vite au lieu de livrer tôt, en livrant régulièrement beaucoup au lieu de livrer continuellement bien. Un logiciel de valeur n'est pas l'addition de ses fonctionnalités. Livrer tôt de la valeur, c'est livrer moins en réduisant le fonctionnel à l'essentiel, jamais la qualité au minimum. Beaucoup d'implémentations "agiles" sont des bévues bâtis sur cette incompréhension.

La première façon de renoncer à la valeur, et par extension aux développements agiles, c'est de ne pas extraire le minimum viable de chaque fonctionnalité. La deuxième, c'est de concevoir le code comme s'il devait l'être en une seule fois.

Si vous souhaitez emmener les gens dans un ailleurs, faites que ce soit une aventure enrichissante et vivez-la vous-même avec enthousiasme et conviction. Sinon abstenez-vous. Un changement sans enthousiasme ni conviction est un changement de direction sans le sens.

© Copyright Chrysocode - Tous Droits Réservés
Mentions légales

Easy Website Builder