Noël approche, avec chaque année la même préoccupation : quels cadeaux offrir ? Idéalement, ce qui fera le plus plaisir et qui ne va pas nous ruiner.
J’étais sur un forum en train de rechercher de l’information au sujet d’un lecteur MP3 lorsqu’un post a attiré mon attention : quelqu’un avec un problème sur une console de jeux demandait si le remplacement du composant fautif allongerait la durée de vie de sa console.
J’étais déjà surpris : j’ignorais même qu’on pouvait remplacer un composant sur une console. Si un condensateur de votre PC tombe en panne, vous changeait la carte-mère complète. Et le plus souvent, vous finissez par changer complètement de machine si celle-ci est un peu ancienne. Au-delà de 3 ans d’âge, il devient difficile de trouver des pièces de rechange, et de toutes façons, il est souvent plus intéressant financièrement d’acheter un modèle plus récent. Continuer la lecture
Best of both worlds
A la suite du post précédent Quelle est la première question ? au sujet des deux questions majeures – coûts vs. risques – quelqu’un m’a demandé si existaient quelques processus ou best practices qui permettent d’atteindre ces deux objectifs.
Existe-t-il un “best of both worlds” afin de produire du code de qualité sans dépasser budgets et plannings ?
Quelle est la première question ?
Je travaille avec des partenaires, certains réguliers, d’autres plus occasionnels. Ils m’appellent quand un de leurs clients a un problème avec une application.
Quel est la première question que vous posez dans un rendez-vous avec un client ?
- Quelle technologie votre application ?

- Est-ce une grosse application ?
- Cette application est-elle complexe ?
Non. Je vois cela tout le temps, et c’est une réaction naturelle : d’abord qualifier l’application.
Bien sûr, vous vous inquiétez de savoir si vous pouvez répondre au besoin de ce client. Bien sûr, votre partenaire cherche á évaluer quel montant possible pour un tel service. Donc ces questions sont légitimes. Mais ce n’est pas la première question. Continuer la lecture
Coûts et risques
Back to raw metrics – Retour vers les métriques élémentaires.
Un client vous confie un audit de la qualité d’une application ou d’un portefeuille d’applications. Il en attend une réponse á une question bien précise. Par exemple :
- Cette application représente une part importante de mon budget : est-il possible de réduire ses coûts et comment ?
- On me demande de reprendre la maintenance de cette application. Je sais simplement qu’il s’agit d’une application complexe. A quoi dois-je m’attendre ?
- Est-il possible d’outsourcer cette application ? Quels sont les risques ?
- Nous allons fusionner avec cette autre entité. Quelles applications utiliser ? Les leurs ou les nôtres ?
Il y a deux questions distinctes dans ces questions:
- Quels sont les coûts ?
- Quels sont les risques ? Continuer la lecture
Amélioration continue de la qualité
Dans le post précédent Mesurer et contrôler, je disais que les métriques quantitatives telles que le nombre de lignes de code (LOC) ou la mesure de la complexité cyclomatique étaient : 
- facilement disponibles – tous les outils d’analyse de code les proposent ;
- exactes – ces mesures ne varient (presque) pas selon les outils ;
- facilement compréhensible pour le management.
Est-ce á dire que les mesures qualitatives seraient difficiles, inexactes et peu utiles ? En fait, tout dépend ce que vous voulez faire, donc du cas d’utilisation. Aujourd’hui, nous verrons un cas idéal : l’amélioration continue de la qualité (Continuous Improvement). Continuer la lecture
Mesurer et contrôler
« You can’t control what you can’t measure » (Tom de Marco)
J’expliquais dans le post précédent Les 3 coûts que les outils d’analyse de code nous fournissaient un grand nombre d’informations qualitatives alors que les métriques quantitatives étaient moins nombreuses, mais très utiles. Cette opinion n’est pas toujours partagée.
Les métriques quantitatives ou ‘raw metrics’ en anglais (que l’on pourrait traduire par ‘données brutes’) sont des mesures assez faciles á obtenir avec la grande majorité des outils d’analyse de code. Généralement, un tel outil commence par présenter une note globale de qualité qui agrège différentes règles en matière de bonnes pratiques de programmation, de design, de documentation, etc.
Cette simple note donne un aperçu général de la qualité de l’application, mais se révèle en fait assez subjective : elle dépend très fortement de l’outil.
Continuer la lecture
Les 3 coûts
Si vous devez investir dans une entreprise, quels sont vos critères de décision ?
Il existe 3 différentes manières d’évaluer la qualité d’une entreprise ou d’une organisation.
L’évaluation financière est la plus simple car elle se base sur des données facilement disponibles : chiffre d’affaires, bénéfices, dépenses, etc… Par contre, elle est assez peu pertinente ou en tout cas peu explicative : vous savez que l’entreprise A et l’entreprise B ont toutes les deux réalisé un chiffre d’affaire de 10 millions et un bénéfice de 1 million. Il est donc possible que ces deux entreprises soient très semblables ou, en tout cas, nous n’avons pas d’éléments qui nous disent le contraire.
Les mesures quantitatives nous permettent d’améliorer la justesse de notre évaluation. Si maintenant vous savez que l’entreprise A réalise ce chiffre d’affaires avec 10 ventes de 1 million alors que l’entreprise B parvient á ce même résultat avec 100 000 ventes de 100 (€ ou $ peu importe), alors vous pouvez déjà imaginer que ces 2 entreprises ne sont pas semblables en ce qu’elles vendent des produits différents et par des canaux probablement différents. Et si l’on ajoute que l’entreprise A réalise son bénéfice sur la moitié de ses ventes et que l’autre moitié n’est pas rentable, alors que l’entreprise B réalise son bénéfice sur 90% de ses ventes et que seules 10% perdent de l’argent, le tableau dépeint par ces données s’éclaircit. Par contre, cette évaluation est plus difficile á effectuer car ces informations sont plus rares et plus difficiles á obtenir. Continuer la lecture
