L'inertie du code versus l'inertie humaine

Quand on parle d'inertie, en informatique, on peut parler de 2 types d'inerties: L'inertie du code qui est en fait la difficulté à laquelle un changement ou un ajustement à ce dernier peut s'effectuer et l'inertie humaine qui peut se résumer à la difficulté à changer un comportement qui s'est transformé en habitude au fil du temps.

Selon vous, quelle inertie est la plus dure à vaincre dans un environnement de développement informatique? Bien qu'il n'y ait pas de réponse facile, je dirais que l'inertie humaine est plus dure à vaincre que l'inertie du code... Du moins, jusqu'à un certain seuil critique.

Pourquoi? Et bien l'inertie humaine/ le refus de changer une manière de travailler entraîne souvent une réaction d'opposition de la part du groupe d'individus impactés face au changement. En effet cette opposition à le pouvoir d'influencer, souvent négativement, les décideurs que le changement n'est pas ce à quoi ils s'attendent lorsqu'ils auront à commencer à travailler avec le nouveau système, et leurs nouvelles façons de faire. L'inertie humaine à la capacité de se transformer en résistance active de la part des individus impactés et plus grand est le changement à l'existant, plus grande est l'opposition.


De son côté l'inertie du code n'a pas un mouvement de résistance semblable et les seuls qui peuvent offrir une réelle opposition à un changement dans le code son ceux qui vont effectuer et connaissent les impacts du changement. Ce groupe d'individus est probablement le moins bien placé non pas pour évaluer l'ampleur d'un changement mais pour offrir une réelle opposition au groupe de résistance du changement humain car

1. Les gens du développement sont généralement financés par les groupes des opérations. Ce fait les place dans la situation ou malgré tout leurs efforts, les groupes opérationnels se sentiront toujours justifiés de prendre la décision de changer le code plutôt que les processus/manières de travailler car ce sont eux qui paient le changement
2. Les gens du développement ne sont pas aussi aguerris que leurs opposants dans l'art de justifier leurs propos. Par la nature du travail de ceux-ci, les développeurs ont moins l'opportunité au quotidien de développer leurs compétences de négociation et d'influence ce qui les place dans une position précaire lorsque vient le temps de débattre des pour et des contre d'un changement..

Pour ces raisons, je crois qu'il est plus difficile de faire passer un changement de processus qu'un changement de code. Passé un certain seuil critique, les changements de code sont reconnus pour être devenus trop coûteux et à ce moment les gens aux opérations sont devant le fait accompli qu'ils doivent changer leur façon de faire, car le changement désiré serait trop dispendieux à absorber dans un budget opérationnel.

Je crois qu'il est important pour un gestionnaire de pouvoir garder en tête que dans un projet de changement à un système, il se peut que la solution finale implique une modifications des processus actuels et peut-être même uniquement des changements à ces processus. Il faut avoir le courage de prendre les décisions difficiles concernant ou le changement doit s'opérer afin de ne pas tomber dans un cul-de-sac qui finirait par handicaper les options de changements à un système. Il faut toujours considérer un groupe opérationnel et ses systèmes comme un tout. Les changement sur un des aspects finiront par influencer l'autre aspect et un nouvel équilibre se créera. L'important c'est de faire en sorte que les changements peuvent s'effectuer dans les sphères les plus appropriées.

L'ère des boîtes noires

Depuis que je travaille en informatique, j'ai pu constater l'intérêt des compagnies pour les fameuses boîtes noires. Ces boîtes est ce que l'on appelle communément des progiciels. Des logiciels commerciaux destinés à effectuer une tâche bien précise.

C'est un concept très vendeur aux yeux des dirigeants qui se font faire un pitch de vente des vendeurs de progiciels. J'aimerais seulement mettre un bémol à l'enthousiasme de la prolifération des boîtes noires dans l'environnement informatique des compagnies.


Voici quelques points qui sont souvent passé rapidement sous silence lors de ces fameux pitchs:

• L'intégration des boîtes dans votre environnement. Sur une acétate Powerpoint, c'est peut-être sexy et seamless de la voir dans votre "nuage" de services déjà en place mais ce n'est jamais aussi simple. Votre architecture de service, souvent construite à partir d'une base de code propriétaire existante, a ses règles propres à elle qui peuvent être complètement distinctes de celles du progiciel. Si la philosophie du progiciel diffère de celle de la vôtre, vous aurez probablement un mal fou à faire fitter un carré dans un triangle. Par exemple, si vous avez plusieurs environnements distincts sur une seule instance de base de données alors que le progiciel ne peut que s'installer qu'une seule fois sur la même instance.
• L'aspect licence d'utilisation est également à vérifier. J'ai vu des compagnies qui osaient charger des licences pour des environnements de tests et de développement. Soyez certains de ces coûts additionnels lorsque vous décidez d'y aller avec la boîte noire
• Par définition une boîte noire est opaque. Vous n'avez donc aucun accès à la mécanique interne de celle-ci et vous pouvez obtenir des surprises plutôt désagréables lorsque vous décider de faire cohabiter le progiciel directement sur un même serveur que vos autres services déjà fonctionnels. La qualité du code de la boîte noire peut être douteuse et il est important de surveiller les indices qui peuvent vous indiquer des potentiels problèmes de performance. Par exemple, j'ai déjà vu un progiciel injecter directement des HINT Oracle dans les requêtes SQL. Ce comportement nous a causé bien des problèmes lorsque nous somme passé de la version Oracle 8i (Rule-Based) à Oracle 10g (Cost-Based)
• Si votre progiciel provient d'une petite compagnie, il existe toujours un risque que celle-ci soit achetée par une plus grosse et qu'ensuite le niveau de service devienne différent (sans compter les coûts d'exploitation) ou encore même que l'application soit mise hors marché. Bien que nous ne nous soyons jamais rendu à utiliser les produits dans un de nos projets, j'ai vu Oracle acheter la compagnie TimesTen et Tangosol alors qu'on étudiait sérieusement ces 2 candidats pour notre projet.

Je ne suis pas contre les progiciels, mais quand on décide d'investir dans ces logiciels, il faut être conscient que celui qui vous vend le produit c'est pas nécessairement la meilleure personne pour déterminer le coût et l'impact réel que ces solutions auront dans votre environnement. Si vous partez vos services de rien, c'est beaucoup plus facile de bâtir avec des progiciels en sachant leur modus operandi!

Développement et maintien d'outils opérationnels

Les groupes opérationnels ont souvent leurs propres outils informatisés. Très souvent ces outils sont développés par les plus "techies" du groupe et ont pour but de faciliter certaines opérations manuelles répétitives ou laborieuses.

Une fois en place, ces outils sont utilisés, reconnus et plus souvent qu'autrement, appréciés des autres membres des opérations et petit à petit deviennent non pas seulement utiles mais essentiels aux opérations. Il y a une évolution naturelle des opérations pour y inclure et intégrer ces outils.

Il faut tout d'abord reconnaître l'effort et l'initiative des gens qui prennent souvent de leur temps pour construire ces outils. Mais en même temps, très souvent, ces même gens ne possèdent pas un background informatique très développé, ce qui amène à une prolifération des outils, tous utiles en soit mais qui ont généralement ces problèmes:

• Certains outils dépréciés continuent d'exister dans l'environnement
  
• Duplication de certains traitement au travers de plusieurs outils
• Une documentation inadéquate (les techies sont la référence)
• Le ratio du nombre d'outils utilisés pour 1 tâche opérationnel est élevé
• Support limité si un trouble est découvert dans ceux-ci
• Qualité organique douteuse
• Ajout de technologies non-nécessire
  

Le gestionnaire d'un groupe opérationnel qui découvre l'existence de ce type d'outils doit mettre en place des processus visant à mitiger les problèmes potentiels:

• Diffusion de la connaissance, non pas seulement fonctionnel mais également technique des outils afin que le "techie" ne devienne pas un élément irremplaçable dans le groupe. Le message que les gens doivent comprendre n'est pas qu'un poste est en jeu mais qu'on veut diminuer le risque de perdre la connaissance acquise et développée par un des leurs. Des exemples de diffusion seraient la tenue d'atelier technique visant à comprendre les technologies derrière les outils ou encore une documentation permettant de s'y retrouver

• Rendre explicite les changements aux outils. Les intégrer aux activités opérationnels. De cette manière les changements à ceux-ci deviennent connus de tous et il est plus facile de suivre l'évolution de ceux-ci au fil du temps et planifier les différentes activités de formation, de modifications et éviter également les changements "sous la couverte" sur des outils qui risquent d'affecter les outils déjà existants

• Un autre point est de tendre à encourager la construction de moins d'outils mais qui représente des opérations en soi. Par exemple, si j'ai une tâche opérationnelle Op1, il est souhaitable qu'il existe un outils Info-Op1 plutôt que d'utiliser 8 outils qui font tous une petite fraction de l'opération. En ayant un seul outils, on diminue le nombre d'opérations manuelles pour effectuer les tâches opérationnelles et la signification et la pertinence de chacun des outils devient beaucoup évident à saisir.

• Finalement, ne pas hésiter à faire appel à des informaticiens qualifiés pour venir encadrer les efforts de développements des gens aux opérations. Il suffit souvent de quelques conseils de base pour grandement améliorer la qualité et la maintenance des outils. Par exemple, quelques bonnes pratiques sur les nomenclatures et une exposition au concept du refactoring peuvent faire la différence!

C'est pas relié aux processus mais...

ça mérite tout de même un petit article... Mon background technique Oracle et mon intérêt pour les subtilités de ce SGBD me pousse à écrire sur un comportement qui cause beaucoup de problèmes de performance dans Oracle 10G (et probablement 11G malgré que je n'ai pas été voir la documentation à cet égard)

De la version 8i à la version 9i, Oracle a modifié ses algorithmes utilisés pour générer un plan d'exécution pour une requête. Il est passé du mode RULE-based à un mode COST-based. Essentiellement, ce passage veut dire que les plans d'exécution générés par Oracle ne sont plus basés sur un algorithme réagissant à des règles déterministes qui s'appliquaient aux requêtes, et cela indépendamment des données sous-jacentes à cette requête. À partir de 9i, les plans d'exécution sont générés en fonction des statistiques (et des chemins d'accès comme les index par exemple). Cette dernière façon permet d'avoir, dans la majorité des cas, un plan d'exécution plus approprié car il est mieux adapté à la réalité des données qu'un plan qui se base sur un ensemble de règles préétablies. Mieux adapté oui, mais le prémisse est que les statistiques sont représentatives de la distribution des données. Depuis 9i, nous n'avons donc plus de "stabilité" out-of-the-box au niveau des plans d'exécution mais les performances en sont généralement améliorées. Des moyens existent pour garder les plans d'exécution (stored outlines) mais ça demeure une fonctionnalité relativement exotique pour la plupart des usagers..

Comme mentionné ci-dessus, tout dépend des statistiques relatives aux données.. C'est là que ça se gâte quelquefois.. Oracle ne peut générer ses statistiques à chaque commande Insert, Update ou Delete. Le coût en ressources serait tout simplement trop punitif. Le chiffre magique qu'Oracle a déterminé, avec sa horde d'ingénieurs, est 10%. Donc si une table finit par avoir 10% d'Insert, d'Update et de Delete combinés, la tâche de générer les statistiques va déterminer qu'elle doit regénérer les statistique pour cette table. 10%, c'est pas beaucoup... sauf quand ta table possède des millions d'entrées. 10% de 10 millions ca demeure 1 million!

Petite parenthèse, Oracle conserve une référence aux nombre d'update, insert, delete dans ses tables. Vous pouvez constater l'état de chaque table dans la vue all_tab_modifications. Lorsque des problèmes de performances apparaissent soudainement dans votre environnement, c'est un bon endroit pour voir s'il n'y a pas un un chargement massif de données ou un traitement qui a changer massivement des données dans les tables..

Pour en revenir à notre cas, c'est clair qu'une table de 10 millions qui a 999 999 données de modifiées va souffrir de cette absence de regénération de statistiques. Il faut donc surveiller de près ces tables volumineuses car elle peuvent clairement affecter la performance de votre système! Dans le cas des chargements massifs de données, la bonne chose à faire est d'intégrer un appel explicite à gather_stats sur les objets impactés pour s'assurer de la validité des nouvelles données car les tâches système de génération de statistiques ne sont qu'exécutées qu'une fois par jour durant la nuit (si ma mémoire est bonne). Ce qui veut dire que si le traitement d'insertion massive est lancé le matin, il y aura des problèmes potentiels de performance toute la journée.


Une petite nuance également à faire attention est que les tâches dbms_gather_XXX_stats par défaut utilise la valeur 'GATHER_AUTO' pour le paramètre 'option'. Pour être certain que les statistiques soient générées, il faut que le paramètre soit 'GATHER'. 'GATHER_AUTO' semble utiliser le chiffre magique du 10% pour décider s'il regénère les stats ou non pour les objets du schéma ou de la BD. Je dis semble car la documentation n'est pas très claire sur l'algorithme utilisé par Oracle alors je présume qu'il reprend la même condition pour regénérer ses stats. Donc si sur 10 millions de records dans la table X, le programme en a modifié 999999 et qu'on lance dbms_stats.gather_database_stats avec les paramètres par défaut, celui-ci ne générera pas les statistiques, et même si l'appel était explicite!

Une bonne pratique qui diminue les risques de troubles de performance est d'isoler les données de travail des données historiques (données déjà traitées). Par leur nature, les données historiques ont tendances à s'accumuler et viennent à chaque nouvelle donnée, augmenter le nombre de données qui doivent être modifiées avant que les statistiques soit regénérées.

Par exemple:

Table A: Contient 10 données: 9 historiques et 1 de travail (pas encore traitée)

Si une donnée est modifiée, alors les statistiques seront regénérées (1/10 = 10%)

Table B: Contient 1000000 données: 900 000 et 100 000 de travail (pas encore traitées)

Oracle va attendre d'avoir 100 000 données de modifiées avant de regénérer les statistiques. Les plan d'exécutions risquent d'être sérieusement impactés.. Un meilleur design serait de séparer les données en 2 tables:

TABLE B1: Contient 900 000 données historiques
TABLE B2: Contient 100 000 données de travail.

Oracle peut donc traiter ces données dans B2 et lancer une regénération de stats après 10 000 (plutôt que 100 000). On peut ensuite transférer les données de la table B2 vers B1 pour que les statistiques soient de plus en plus sensibles aux changements.

On peut ensuite créer une vue B
B1
UNION
B2

qui abstrait cette séparation physique à l'usager...


Alors ça fait le tour de mon propos moralisateur sur les dangers des statistiques pour aujourd'hui ;)

Réflexions sur la gestion des demandes clients...

Au cours de ma carrière professionnelle, j'ai eu la chance jusqu'à présent de cotoyer plusieurs personnes de talent. J'ai récemment eu une bonne discussion avec un de ceux-ci concernant l'importance de la traçabilité des demandes clients versus l'approche agile qu'il employait. Nous étions en désaccords sur le fait qu'il faut garder une trace de toutes les demandes clients. De mon côté, j'essayais de lui faire comprendre qu'il est important de noter ces demandes car l'information provient du client et de ne pas s'en soucier jusqu'à ce que le client revienne à la charge sur cet item pourrait devenir un irritant majeur pour ce dernier s'il est constamment en train de réitérer ses demandes ou qu'il s'aperçoit que des oublis sont survenus. Pour sa part il était évident que travailler sur des demandes qui sont souvent périmées ou moins appropriées qu'au départ était une perte de temps qu'une équipe de développement agile ne pouvait se permettre. En y pensant bien, il avait raison et j'étais d'accord avec ses arguments. En fait, nous avions probablement les deux raison. Dans une mentalité agile, les priorités de développement sont établies par le client et non par les développeurs. La distinction importante est de savoir qui gère la pile de demandes. L'équipe de développement, le gestionnaire ou le client? À bien des endroits où j'ai travaillé, c'est souvent le gestionnaire du développement qui est responsable de gérer la pile de demandes. Le client a souvent un rôle passif qui consiste à inscrire une demande et attendre qu'elle soit traitée dans une livraison future. Bien souvent le client n'est impliqué que sporadiquement dans le processus de développement. Il faut donc tendre a impliquer le client pour qu'il décide lui-même de la pertinence de chaque demande, basée sur l'état d'avancement actuel du produit et faire une réévaluation fréquente des priorités. Les priorités du développement sont donc alignées avec les besoins du client, le client paie pour du développement concret qu'il sait pertinent et que fait le gestionnaire du développement dans une telle dynamique? Il coopère avec le client afin de l'aider à conserver la traçabilité de la totalité de ces demandes,c'est lui qui met à jour la pile de priorités spécifiées par le client pour l'équipe de développement, il maintient ce processus de développement (certains peuvent volotairement ou involontairement tenter de modifier la priorisation client) et c'est lui qui assure la communication officielle (ex: état d'avancement et autres métriques pertinentes) avec le client. Comme conclusion je dirais que la traçabilité demeure importante mais l'imputabilité de celle-ci revient au client et non à l'équipe de développement puisque ce sont ses demandes et non celle de l'équipe. Ceci étant dit le gestionnaire, qui est en fait un facilitateur d'un côté comme de l'autre, doit aider à maintenir cette traçabilité et ce processus.

Conférence AgileTour à Québec en octobre 2009!

Québec est inscrite dans la liste des villes visitées par le AgileTour 2009. Peu de détails sont connus pour le moment mais déjà Mary Poppendieck (elle qui est derrière l'approche Lean Software Development) est confirmée comme conférencière. Pour plus de détails:

http://www.agiletour.org/en/quebec.html

À suivre!

Gestionnaires de projets et les symboles de statut

Vous êtes un gestionnaire de projets et vous avez au fil des ans cumulé gloire et récompenses par vos accomplissements. Votre cubicule (ou bureau pour les plus chanceux!) regorge de diplômes, de prix que votre entreprise vous a décerné et de lettres d'exécutifs signés à même leur main. D'un autre côté votre équipe de développement semble distante et les communications ne sont pas aussi directes que vous le souhaiteriez? C'est peut-être en partie dû à vos symboles de statut.

En effet, en étalant vos accomplissements au grand public vous avez peut-être créé un fossé entre vous et les gens qui vous entourent. Les gens peuvent se sentir intimidés face à tant de succès et peuvent être réticents à partager avec vous l'information dont vous avez besoin pour prendre les bonnes décisions au niveau de la gestion du projet. Ce phénomène n'est pas nécessairement effectué consciemment mais il reste tout de même perceptible. Vous n'y croyez pas? Repensez à comment vous vous sentiez la dernière fois où vous avez eu une information loin d'être positive à faire passer à votre supérieur ou à un exécutif. Il y a fort à parier que le message original a soit été remanié pour sonner moins alarmant soit complètement omis craignant les conséquences d'un tel discours. C'est un peu comme le langage verbal versus le non verbal: On a beau dire "oui" en parlant si notre tête fait le mouvement symbolisant "non", la personne en face de nous le remarque et l'incongruence est notée.

Le gestionnaire de projets doit tendre à ouvrir les communications entre lui et les membres de l'équipe et il a tout à gagner à éliminer les obstacles qui peuvent le ségréger de son équipe. S'il veut encore plus s'impliquer et éliminer les barrières communicationnelles ce dernier relocalisera son bureau en plein coeur de l'endroit où travaille l'équipe de développement. Trop souvent les gestionnaires de projets sont regroupés ensembles dans un secteur et loin de l'activité de développement qu'ils gèrent.

Donc éliminez vos symboles de statut, rapprochez vous de votre équipe et intégrez-vous à votre équipe pour diminuer les "angles morts" communicationnels.

Si vous voulez en savoir plus sur les symboles de statut, je vous invite à lire "Psychology of Computer Programming" de Gerald Weinberg. c'est un excellent livre et je vous recommande fortement de lire au moins un de ses livres si les processus informatiques sous intéressent!