jeudi 27 août 2009

De l'agilité des légos et des logiciels afférents

Il faut bien avouer cette sombre évidence : un informaticien cherche toujours à ramener son travail à un jeu de légo.

Loin d'être un trouble obsessionnel compulsif, il lui semble que le monde devrait être plus simple, et devrait normalement se soumettre à la réduction induite par la modélisation.

Si la construction d'application s'apparentait à des Légos comme le sous-entend OSGi, on n'aurait pas besoin de développeur, il suffirait d'emboîter des composants les uns dans les autres. Or, l'innovation d'une application n'est pas là. Vous pouvez faire de très belles constructions en légo, mais l'utilité de celles-ci restera à démontrer par l'expérience. Le simple rapprochement de fonctionnalités dans une combinaison originale peut s'avérer intéressante dans certains cas, et toute une profession s'en contente largement en attendant la prochaine véritable innovation.

Au delà de la réduction à un jeu de légo, nombreux sont ceux qui cherchent à insuffler une marque de sérieux à une activité dénigrée dès qu'on prononce son nom : la programmation. Le mot programmation est connoté négativement par tous les professionnels et clients du secteur informatique. Ce terme ramène trop à la base de l'activité, au travail le plus bas niveau et pourtant le seul qui produise de la valeur réelle : la création d'un programme en vue de le faire exécuter par l'automate informatique. Pour cacher la dure réalité d'une profession de tapeur à la machine, nombre d'informaticiens ou pseudo-informaticiens se vêtissent d'un jargon sans cesse renouvelé pour mieux périmer les vieux termes et ceux qui les utilisent encore.

Aujourd'hui, seules les méthodes "agiles" sont considérées comme crédibles. Une pratique de développement logiciel qui ne s'apparente pas au mouvement "Agile" est à priori suspecte. L'ajout d'un adjectif comme agile à des noms déjà vagues, prête souvent à confusion, car cela pousse à croire que les objets en questions sont relatifs. Cela s'apparente au relativisme ambiant : le relativisme culturel que des intégristes religieux cherchent à promouvoir pour justifier leurs agissements dans certaines contrées, ou comme dernièrement, le Président de la République Française avec sa "Laïcité positive" (sous entendu, il existe une laïcité négative). Une méthode agile exclue toutes les autres et les ramène au rang de méthodes forcément non-agiles, donc lourdes, dépassées, ...

Hep, Hep, toi qui veux être dans le coup, sache que "Agile" est maintenant un terme dépassé, il faut parler de ARxTA ... "Agile", comme tout terme-réclame est utile aux professionnels, tant pour les clients que pour les fournisseurs de solutions. Cela permet de rapprocher des points vus autour de mots clés clairement identifiés, ce qui créé une sorte de communauté avec ses codes, son jargon, ses pratiques, techniques et traditions : une véritable culture en sorte.

Au delà de ces mouvements passionnés, des individualités surgissent, émergent, montre les nouvelles cimes à atteindre par leurs actions au jour le jour. Il est toujours étonnant de voir que malgré les énormes entreprises commerciales aux bénéfices records (même en ces temps de crise), de simples individus arrivent à imposer leurs créations comme autant de nouvelles évidences pour la profession. C'est pourtant dans de petits bureaux, dans de non moins petites salles IRC de discussions que se forgent les technologies de demain. Une startup sait qu'elle est sur la bonne voie quand elle peut produire son application sans recours à des fonds extérieurs, ces fonds ne servant qu'à accélérer plus ou moins un mouvement incessant et irréductible, dirigé vers la réussite.

Pour illustrer la capacité d'un individu à produire de petites merveilles, j'ai pensé vous faire profiter de la voix cristalline de Imogen Heap qui, aidé par un MacBook il est vrai, arrive, à elle seule, à oindre de saintes notes de ses propres mains dans nos esgourdes.



Non, on a beau dire que la perfection n'est pas de ce monde, mais le chemin de l'excellence cherche à nous y mener en tout cas, chaque jour nous ramenant à la dure réalité et à notre propre dépouillement face à la grandeur des exigences et contraintes de nos applications. Ce n'est pas ce qu'on appelle le mythe de Sisyphe ?

jeudi 20 août 2009

Grippe A (H1N1) : l'avez-vous mise dans les risques de votre projet ?

La grippe A (H1N1) va (ou est déjà) arriver massivement en France, avec normalement un pic en septembre 2009. Ce n'est pas une grippe qui semble plus grave qu'une autre mais elle a la particularité d'être très contagieuse. Ce qui veut dire qu'il y a un risque réel d'avoir 5 % à 15 % des effectifs des projets absent 1 ou 2 semaines un jour ou l'autre pour arrêt maladie. Ce peut être aussi des parents qui s'absentent pour garder leurs enfants car ceux-ci ne peuvent plus être reçus à l'école pour cause de grippes trop nombreuse dans leur classe.


En bref, la probabilité d'avoir des ressources en moins sur les projets est très forte et doit normalement être prise en compte dans votre suivi des risques, sous peine d'avoir de grosses surprises et d'autant plus grosses déconvenues sur les estimations des délais de livraison.

Si vous pensez pouvoir arguer que vos retards de livraisons sont dus à la grippe et que votre client ne va pas ciller face à cet argument, bien à votre aise de ne pas suivre ce risque et de laisser aller vos projets tels qu'ils sont aujourd'hui.

Dans le cas contraire, il est temps de suivre le risque, de se préparer à contrer les absences, ainsi que renégocier les modalités de livraison avec vos clients : vous pouvez toujours tenir vos délais et enlever certaines fonctionnalités de la listes des fonctionnalités obligatoires à livrer (les mettre alors dans la listes des fonctionnalités "si possible").

En tout cas, il faut être clair avec le client sur ce risque pour éviter toute surprise mal venue.

Il est toujours inquiétant de voir que dans certaines sociétés, le rythme des projets et des livraisons envisagées n'a pas baissé, voire a même augmenté pour répondre à la crise. Mais c'est prendre un gros risque que d'ignorer ce qui va arriver de façon quasi certaine. Le fait qu'on ne maîtrise pas les impacts de la grippe n'est pas une excuse pour ne pas les anticiper.

Que vous soyez chef de projet, directeur de projet ou simple exécutant, pensez à voir l'impact de votre absence ou de l'absence de vos confrères sur les projets sur lesquels vous travaillez. Je serais vous, je ne prendrais pas d'engagement inconsidérés durant la période de cette rentrée 2009. Mais qui prend d'ailleurs d'engagements inconsidérés ? Le tout est de considérer que les changements sont inévitables sur les projets, et il s'agit de les gérer explicitement.

jeudi 13 août 2009

Dates cibles et échéances : compromis comme promis

Tout le monde a, un jour, travaillé sur un projet si mal défini ou si maladroitement suivi qu'on a plus qu'une seule envie : quitter le radeau avant qu'il ne coule. Vu la proportion gigantesque de projets ne respectant ni ses délais, ni son périmètre initial ou ses coûts (source), il est très probable que vous ayez déjà participé à ce genre de fiasco.

Dans les projets à la dérive, les échéances (deadlines) sont souvent dépassées, faisant éclater des disputes sans fin dans le but de trouver des coupables, mais surtout pas d'essayer de remettre de l'ordre pour la suite du projet.

Quand ces horribles projets finissent par mourir définitivement (et ça peut prendre beaucoup de temps !), il est toujours intéressant de se pencher dessus à froid, pour essayer de comprendre ce qui n'a pas marché. Ce travail de reflexion à posteriori (les anglosaxons aiment bien utiliser le terme « project post-mortem ») est malheureusement trop rarement effectué, ou seulement de façon incomplète.

Sur plusieurs de ces projets, on s'aperçoit que les échéances ont été définies avant même d'estimer quoique ce soit sur le projet. De plus, ces dates n'ont jamais été remises en causes pendant toute la durée du projet. Est-ce que ce sont réellement des échéances (deadlines) ou seulement des dates cibles (« target dates ») ? Une date cible est bien différente d'une échéance. C'est ce que décrit clairement Conrad Weisert dans son article « Les échéances et dates cibles des projets : 5 conseils pour éviter le désastre » :
La plupart des « échéances » (deadlines) ne sont en fait que des dates cibles. La différence réside dans ce qui survient si la date n'est pas respectée :
  • quand une échéance est ratée, il ne reste plus aucun intérêt à compléter l'engagement. Par exemple :
    • s'inscrire à une compétition
    • publier le catalogue de Noël prochain
  • Quand une date cible est ratée, les conséquences peuvent être aussi désastreuses que pour une échéance, mais vous avez toujours à finir le travail. Si « date cible » semble trop vague pour vous, alors remplacez cette expression par « date de fin » ou « date de livraison ».
Encore faut-il gérer correctement la planification d'un projet de développement pour pouvoir définir des dates cibles ou des échéances. Cela nécessite de maîtriser un tant soit peu l'art délicat de l'estimation et d'être en mesure d'offrir des preuves de celle-ci.

Sur son site, Conrad revient sur ces notions importantes, en relation avec la gestion de projet et le développement logiciel. L'estimation n'est pas qu'une affaire d'expérience. C'est aussi et surtout le moyen de montrer par « a + b » qu'un projet tiens la route et saura tenir ses délais. Or seul celui qui dit que quelque chose peut être fait doit en apporter la preuve. Un client ou une division Marketing d'une entreprise se doit d'être ambitieux quant à la définition du produit et à ses dates de livraison ou de mise sur le marché. Or ce n'est ni le client ni cette division marketing qui vont prouver qu'on est capable de réaliser ses rêves. C'est au chef de projet (ou au chargé d'affaire dans le cas de sous-traitances de développement) de trouver des solutions qui puissent répondre au mieux aux exigences et contraintes exposées.

La définition de plan permet d'éclaircir le projet et de notamment exprimer de nouvelles exigences et contraintes liées aux solutions. Ce n'est qu'en face des éléments issues de toutes les parties que l'investisseur (le client, la division marketing...) lance le projet.

Dans le cadre de la sous-traitance de production (pour le développement logiciel au forfait par exemple), il est facile pour un chef de projet de se faire imposer des dates cibles du simple fait:
  • de la relation contractuelle qui existe entre le client et son cahier de charge d'un côté, et le fournisseur et sa volonté de gagner le contrat de l'autre (souvant « à tout prix »).
  • de la rédaction de la réponse à l'appel d'offre par une personne (un « chargé d'affaire ») autre que celui qui va mener le projet jusqu'à son terme.
Même dans le cas de sous-traitance, il est souhaitable que la réponse à l'appel d'offre soit ambitieuse et rédigée par une personne autre que le chef de projet, car ce dernier a naturellement tendance à voir énormément de risques et à avoir une attitude extrêmement prudente, encore plus s'il n'est pas « intéressé » personnellement (oui, oui, par cette basse chose qu'on appelle « l'argent ») au projet. Mais c'est au final, au chef de projet de ramener tout le monde à la réalité.

jeudi 6 août 2009

AJAX et Performance : un oxymore

N'avez-vous pas l'impression qu'AJAX (Asynchronous Javascript and XML) nous ramène en un temps où les ressources matérielles étaient chères et lentes, où les compilateurs ne savaient rien optimiser et qu'il était difficile de fiabiliser son code ? Développer en Ajax, c'est retrouver le bidouillage d'antan, quand il fallait lutter à chaque pas contre les limites du système cible. Oui, ce satané Javascript qui a plus à voir avec Lisp qu'avec Java, est bien la cause de ce problème. Où plutôt la mise en œuvre de ce langage dans un paradigme (AJAX) créé dans le but unique de palier aux problèmes d'un autre paradigme (le Web) pour obtenir des applications d'un paradigme historiquement éprouvé (le Client-Serveur).

En effet, les technologies supportant l'AJAX sont plus qu'inefficaces, elles sont inappropriées. Les navigateurs Web ne sont pas conçus à la base, pour être des plateformes d'exécution d'application.
Javascript a été mis en place dans les navigateurs (Netscape Navigator à l'origine) pour palier à l'aspect statique des pages et du protocole orienté document qu'est HTTP.

Pour que Javascript s'exécute rapidement, il a donc fallu implémenter un interpréteur très simple et ne réalisant que peu d'optimisations. On ne retrouve pas en Javascript les optimisations que l'on considère comme évidentes dans n'importe quel autre compilateur :

Il faut donc coder en Javascript d'une manière spécifique, en connaissance de cause. Cette leçon nous est donnée par Douglas Crockford dans sa présentation « Ajax Performance ». Il nous donne quelques exemples puis exprime la philosophie générale de l'optimisation Ajax : Alors qu'il est logique de penser qu'il faut toujours essayer d'avoir des algorithmes de complexité en O(1), O(log n) plutôt que O(n), O(n2) ou O(en), l'important est d'avoir n le plus petit possible quelque soit la complexité. Le client Ajax n'est là que pour présenter une vue réduite des données du serveur.

Ce qui est étonnant c'est l'intitulé de la série de présentation de Douglas qui s'appelle « Javascript : the good parts ». Je comprend bien qu'il veuille prêcher pour sa paroisse, son langage de prédilection, mais heureusement qu'il a un œil critique sur sa technologie fétiche et montre bien qu'il faut aller bien loin pour trouver de « bons côtés » à Javascript. Il a du vouloir attirer tous les zélotes de l'Ajax et du javascript à sa présentation pour mieux leur montrer les limites de leurs croyances. Car toute « nouvelle » technologie , s'apparente plus à l'émergence d'une secte qu'à une avancée scientifique majeure. AJAX n'est plus très nouveau d'ailleurs.

Heureusement la réalité est toujours là et les « bonnes pratiques » informatiques sont toujours d'actualité même en Javascript. Douglas ne fait que reprendre à raison les principes éprouvés de l'optimisation de code.

On a beau critiquer Javascript, on peut aussi l'apprécier pour ses aspects qui le différencient tant de Java justement, comme par exemple : l'héritage par prototype, la programmation fonctionnelle que l'on peut en faire, notamment, grâce aux fonctions d'ordre supérieur. Le Javascript est, de fait, un des langages les plus utilisés aujourd'hui.

Ça peut être amusant de faire de l'Ajax (c'est d'ailleurs quelque chose que nombre de développeurs réalisaient il y a de cela déjà bien longtemps, avant même qu'on y mis un nom dessus) mais franchement, aujourd'hui, ce qui est le plus productif c'est de ne carrément pas coder du tout : utiliser des outils pour générer les interfaces graphiques et des applications.

Qu'on le veuille ou non, le coût d'un développeur français est tellement élevé par rapport à un développeur indien (7 à 10 fois son prix) par exemple qu'il devient complètement improductif de lui demander de développer à la main des applications Ajax.

En france, à Montpellier, il y a PC SOFT (un nom de boîte qu'on imagine sans hésitation sortir des années 80) qui produit WEBDEV dans le même esprit que WINDEV. Parmi mes collègues développeurs, rare sont ceux qui préconise de développer avec de tels outils de génération d'application. J'ai l'impression qu'ils disent cela parce que WINDEV est vieux et que tout ce qui est vieux en informatique devient plus ou moins ringard.

Personnellement, leur nouvel outil WEBDEV semble intéressant pour produire des applications Web / AJAX sans coder quoi que ce soit. Pour la plupart des petites et moyennes applications, c'est largement suffisant car ce sont essentiellement des applications de gestion de l'information. Dans le cas de besoins spécifiques, on peut toujours développer spécifiquement une extension et l'intégrer à l'application.

Il existe aussi Oracle Application Express pour la génération automatique d'application au dessus d'une base Oracle sans écrire une seule ligne de code. Ce composant est souvent disponible chez les client qui ont achetés des licences database serveurs, sans qu'ils le sachent vraiment. Le client paie cher des technologies dont seulement 10% sont réellement utilisées (et ces 10% se retrouvent souvent aussi bien en Open Source...)

Tout cela va dans le sens de considérer XML, HTML, CSS et Javascript comme étant du binaire illisible qu'il s'agit de traiter uniquement via des outils de haut-niveau et des ateliers de génie logiciel (AGL). Seul les développeurs de composants et d'atelier logiciels ont à se pencher sur ces technologies au jour le jour.