Mickaël’s Weblog

Le développement logiciel d’un module peux se faire de plusieurs façons différentes. On peut le coder en une fois en prenant en compte tous les cas d’utilisation (connus et potentiels). On peut également en faire une première version en prenant en compte tous les cas d’utilisation connus tout en sachant qu’il faudra la réécrire pour l’étendre. A l’extrême, on peut coder à minima, en ce disant que le design n’est pas important et au final revenir 1000 fois dessus pour coder…tout ce qui manque.

D’où la question: “Quelle est la meilleure ?”

Première remarque: il n’y a pas de méthode “meilleure”, mais elles ont toutes des avantages et inconvénients propres différents, à vous de choisir en fonction de vos objectifs et des moyens à votre disposition. Ce qui est sur: c’est qu’il n’y a pas de (recette) miracle. Au bout du compte, une fonctionnalité a un coup lié à sa complexité/difficulté, et donc requiert un investissement a peu près identique quelque soit la méthode…mais un retour sur investissement différent suivant vos objectifs.

Prenons le cas du codage en 1 fois, plus communément appelé : “usine a gaz”.  L’idée est de confier ce module a un seul développeur qui part “en sous marin” pour coder le module afin de répondre aux besoins connus…mais aussi suffisamment extensible pour intégrer des nouveaux besoins très rapidement. Pour caricaturer, c’est la tendance naturelle d’un développeur, car cela lui permet de ne se consacrer que à cette tâche, il travail seul, décide seul, doit faire appel a ses connaissances d’expert (pour l’extensibilité), et enfin démontre que le management lui fait confiance…c’est gratifiant. Quand on a un développeur capable d’anticiper les besoins futures, de coder de manière efficace et propre, c’est certainement la “méthode” qui permet d’avoir le module complet le plus rapidement…sauf que ça c’est la théorie, et que cela se passe autrement dans 95% des cas. En effet, il y a souvent un nombre important de bugs, l’extensibilité n’est souvent pas au rendez-vous et du coup le moindre besoin supplémentaire demande un “refactoring” important et pas si simple que ça. L’autre effet indésirable, est le non partage de la connaissance du code…et c’est souvent du code assez complexe (d’où le terme ”usine a gaz”). Autre inconvénient majeur: il faut attendre en général d’être aux 9/10 de l’implémentation pour voir quelque chose tourner/fonctionner.

Mon responsable R&D d’il y a 10 ans disait toujours: “de toute manière c’est toujours la 3ième implémentation la bonne…il faut donc toujours tout refaire au moins 2 fois”. On commence a sortir de l’usine a gaz, car les ambitions de la première implémentation sont plus raisonnable et se cantonne aux besoins connus (enfin 90%). De toute manière, y aura la seconde implémentation pour corriger ce qui ne va pas et intégrer les nouveau besoins! Autre avantages: un retour sur investissement plus rapide…même si l’implémentation est moins complète, moins de complexité, et donc aussi en général moins de bugs. Au bout du compte, on va avoir [sur une base de 3 implémentations] investi autant: moins de temps à définir les spécifications, plus en dev, moins en bug fix, moins en QA. Si on a un staff QA plus réduit, on y gagne. On peut mettre sur le marcher ce module plus tôt. Et si on fait faire le développement a différent développeurs, on a un meilleur partage de la connaissance (et on a perdu en efficacité car il faut former chaque développeur).

Poussons le raisonnement du nombre d’implémentations à l’extrême : 1000! On réduit a minima les spécifications, on ne se concentre que sur le plus important (1/1000ième de la fonctionnalité), et on n’anticipe aucun besoins non connu. On ne peut cependant pas se permettre de faire les 1000 itérations/implémentations les unes derrière les autres, avec phase de spécification, implémentation, test, documentation, transfert de connaissance…il faut une extrême fluidité dans la communication associé à une polyvalence de chaque développeur (et oui, il va faire le dev, la QA, la doc et le design).

Au bout du compte, quel est l’investissement total suivant chaque méthode ? Définissons d’abord ce qu’est l’investissement total. C’est l’ensemble des ressources qu’il aura fallut mettre en place pour avoir un module qui fonctionne correctement (les clients en sont satisfaits), et donc le code ne bouge quasiment plus (peu de bugs).

La première méthode apparait comme la plus rentable, mais le risque (devoir refaire une autre implémentation) est très élevé (et là cette solution devient la moins rentable), et souvent la qualité n’est pas au rendez-vous. Deplus, seul un développeur connait le code…ce qui peut poser d’énormes problème de maintenance.

1000 intérations apparait comme la méthode la moins rentable, mais la capacité d’adaptation a des nouveaux besoins est excellente et on délivre bien plus rapidement…et ça, c’est de l’argent. Cela demande cependant d’intégrer redesign et tests a chaque itération.

C’est donc à vous de choisir suivant les ressources, le contexte, le objectifs.

Il y a cependant une pratique dont j’ai pu observer qu’elle ne fonctionne pas quelque soit la méthode. Le fond du problème est la gestion de la dette technique qui mène au “refactoring”. La première méthode consiste a réduire à 0 cette dette pour éviter tout refactoring. Le problème est que le risque est très élever de ne pas y arriver, et on s’en aperçoit souvent trop tard. Augmenter le nombre d’itération consiste à admettre cette dette technique et de la compenser par des itérations/implémentations supplémentaires. Le piège est de consacrer ces itérations uniquement à la dette. Le résultat est d’avoir des itérations sans valeur ajoutée, et du coup une incompréhension du product management quand a leur utilité. La “bonne” pratique consiste a apporter de la valeur ajouter à chaque itération, tout en remboursant une partie de la dette.

Au final, ayez une stratégie de remboursement de dette qui correspond a vos objectifs et à vos resources.

Les méthodes agiles assurent-elles le succès d’un projet de développement?
La réponse est clairement non. Ayant pratiqué plusieurs méthodologies (agiles…ou pas), il m’apparait clairement que c’est avant tout l’existence d’une méthode et son adhésion qui est la condition nécessaire, mais pas suffisante. Ne pas avoir mis en place de méthode est la garantie d’un désastre, et la responsabilité en incombe au management. Il faut de plus que l’ensemble des acteurs y adhèrent: équipe et client. Ce n’est pas chose facile, mais le management n’est pas une chose facile. Il faut enfin que le déroulement du projet ce fasse en toute transparence vis-à-vis de l’équipe et du client.

Mettre en place une méthode efficacement n’est pas aisée. Dans le cadre d’une SSII par exemple, les méthodes agiles sont souvent opposées aux contrats de type forfait. Il est vrai qu’au prime abord cela peut sembler vrai, mais c’est a mon avis juste une question d’approche, et au final les SSII travaillent de plus en plus en mode Agile. Sur ce sujet, Pascal Van Cauwenberghe a écrit 2 excellents articles à ce sujet: Succeding with Agil Fixed Price projects (part 1 et part 2). Les plus gros obstacles sont souvent la méconnaissance ou les fausses évidences.

Le plus important est la mise en place d’une méthodologie, ensuite il faut considérer tous les paramètres du projet dont le contexte d’éxécution (taille d’équipe, durée du projets, objectifs, priorités..etc), et choisir la méthode la plus appropriée, la modifier suivant les besoins et l’exécuter en toute transparence
.

…et notamment dans les secteurs du logiciel et des R&D. La france s’en sort plutôt bien au niveau de la productivité par heure travaillée. Dommage que ces statistiques ne donnent aucun chiffre sur les pays “off-shore” dans le développement logiciel : chine, inde, roumanie…etc.

Suite à mon exploration de Google App Engine Patch (AEP), j’ai regardé de plus près les framework de tests. Le constat global est que l’on nage un peu dans le monde de l’Open Source: plétorde de possibilités, mais au final aucune ne matchant parfaitement mes besoins (j’exagère délibérément mais cela donne ce sentiment).
Le premier fautif est certainement Google lui même. Je suis d’accord avec Michelschr quand il dit que Google devrait fournir les outils (ou API) pour que les développeurs suivent les bonnes pratiques de développement. Cela m’étonne effectivement d’autant plus que Google a une excellente équipe dédiée aux pratiques du test.
Au final, on tombe sur une myriade de framework adressant dans aspects différent du test. Il est alors très dur de trouver celui qui convient, et souvent il ne fonctionne pas parfaitement bien du fait que par exemple il est adapté à Django, mais pas à AEP.

J’ai donc réduit mes recherches sur les tests unitaire (et non pas fonctionnel). AEP étant basé sur Django, qui est un framework MVC, il me semblait évident de trouver quelque chose d’adapter a ce genre de tests. Ma première surprise fut de constater que Gaeunit exécute les tests dans l’environnement Google App Engine (GAE)…et non pas dans le SDK. C’est a mon avis utile, mais plutôt pour des “smoke” tests ou tests de prod. J’ai donc écarté cette option.
J’ai regardé ensuite les possibilités du coté de Django. Je ne suis vraiment pas fan du test-per-class où l’on associe systématiquement une classe de test par classe de code. Doctest, lui intègre les tests dans chaque fonction. Je préfère de loin placer les tests au niveau de la fonctionnalité ou du “comportement” (BDD) qui repose moins sur le refactoring qui est toujours plus délicat sur les langages dynamiques.
Autre possibilité: unittest de Django. Il est certainement possible de faire tourner ces tests dans le SDK AEP, mais cela ne fonctionne pas out-of-the-box. Django est en effet patché au vol par AEP et cela complique la mise en place de ces tests.
J’ai donc recherché quelque chose de simple, avec comme seuls pré-requis: ne fait pas intervenir d’url mais permet de “rendre” les template, et permet de mettre les tests dans un répertoire séparé des sources. J’ai au final utilisé gaetestbed (qui est très light), avec Mock, plus quelques classes permettant de créer des “fausses” requêtes HTTP POST et GET. J’utilise nose pour lancer mes tests.
Au final, j’arrive a tester l’ensemble MVC en total isolation (pas de browser, authentification mockée…etc). Il est claire que cette solution est restreinte à ce type de tests…mais pour l’instant je n’ai besoin que de cela. A noter que le DataStoreTestCase ne permet que de savoir le nombre de requetes exécuté…ce qui est clairement très insuffisant. En regardant de plus près, c’est GAE qui n’expose quasiment rien…je vais certainement devoir mocké (en stub) pour améliorer cela…a voire.

Depuis quelques semaines je me suis intéressé a Google App Engine. Cela m’a permis de “rafraichir” mes connaissances Python, de regarder de plus près l’offre “Cloud” de Google, et aussi les problématiques de déploiement associées.

J’ai dans un premier temps utilisé l’intégration Django avec GAE. Première constatation: la mise en place de l’infrastructure —pourvu que l’on prenne bien les bonnes versions des composants — est vraiment simple, rapide et on crée son application “hello world” très rapidement.

En revanche, dès que l’on doit creuser un peu dans les fonctionnalités, la documentation n’est plus au niveau. Surtout que Django est quelque peu brutalisé/modifié car on utilise BigTable. Autre inconvénient: il faut quand même tout développer soit même car le framework WebApp fournit dans GAE est relativement “fin”. On est donc loin d’avoir une stack applicative bien étoffé.

Je suis donc passé à GAE patch…et là on a vraiment à notre disposition un framework suffisamment développé pour supporter du développement rapide d’applications. On a effectivement un pseudo-container d’applications avec:

• service d’authentification,
• application d’administration,
• service de cache,
• service de mail (et XMPP)
• MVC (Django et ragendj)

Je suis tombé sur ce billet du Dr Goulu sur la motivation dans le monde du travail. Il s’appuie sur la présentation faite par Daniel Pink sur la science de la motivation.

Ayant travaillé dans différents environnements (de la startup à la très grande entreprise), j’ai pu clairement constater que la motivation était clé. Je suis persuadé qu’on peut facilement doublée la productivité quand une équipe est très motivée. On peut aussi la diviser par 10 si elle est démotivée. Et surtout, dans un domaine comme le développement logiciel où les solutions ne sont jamais idéales et demandes beaucoup de créativité, une équipe motivée trouvera des solutions souvent bien meilleur.

Daniel Pink plaide que la science a démontré bien des fois que les “bonus” fonctionnent bien pour des tâches plutôt mécaniques ou dont la solution est simple a trouver. Dans les autres cas, les “bonus” dégradent les performances. Cela ne veut pas dire qu’il faut supprimer les “bonus” en développement logiciel (qui demande créativité sur des problèmes complexes et toujours différents), mais que cela ne va certainement pas augmenter la productivité et la motivation. En revanche cela permet d’éviter que vos têtes pensantes n’aillent penser dans une autre entreprise.

La deuxième partie de la vidéo parle de l’autonomie et des expériences prouvant que l’autonomie est source de créativité. Ils parle des 20% de temps que Google accorde a ses employé pour faire ce qu’ils veulent et que au final, la moitié des projets les plus connu de Google…viennent de ces 20%.

J’ai pu constater que la productivité est clairement lié a la motivation, et que l’autonomie est une grande source de motivation. Il passe un peu vite sur les “objectifs” qui a mon sens sont aussi très important. Car même si une entreprise laisse ses employés faire ce qu’ils veulent 20% de leur temps, il est important que les 80 autres pourcents permettent d’atteindre des objectif. Je trouve que les méthodes agiles de développement logiciel sont un excellent moyen d’y arrivé par la responsabilisation des membres de l’équipe et non par un manager qui décide tout, distribue les tâches et centralise la communication.

Bref, une vidéo a voir absolument (anglais, sous-titres français).

Google vient d’ajouté le support de XMPP dans AppEngine. Le Web 2.0 (certain versés dans le marketing diraient Web 3.0) fait une part belle a l’interaction, et le chat en ait bien sur un des pillier. Des APIs wave seront certainement ajoutées bientot. En effet, wave est basé sur XMPP.

I had a very “interesting” discussion with a colleage about an API that he would like to expose through REST. This API is suppose to check a SQL where clause. He suggested to expose it as REST as we are currently working on some REST engine for our backend.

This option appeared as the simplest and quickest….and I like simplicity. But simplicity is much more than a low number of LOC. In our case, the number was low thanks to the support of a REST SDK. To check about simplicity, the usage of third party should be taken into account. So, I get ride of the false argument about simplicity. The argument that the implementation is quick todo is also NEVER an…argument, this is just a fact.

Without these argument, the discussion start to be “interseting” …I erejct the idea to implement it as a REST API as REST seams not to fit at all in this picture. My argument was “this is a service, not a resource”. I get the classic “everything can be a resource, this is just a question of point of view”. You can read this excellent post from Cragg Ducan.

It does not make sense to get the collection (or list) of valid SQL, it neither makes sense to delete or put/post on a SqlValidation resource.

Then I tries to find some obvious example of service that just can’t fit into a REST paradigm. My goal was to demonstrate that REST is not “one-size-fit-all” paradigm. I can’t rely on the fact that some verbs as DELETE or PUT will not work as this is already often the case. But, I can rely on the fact that the GET is not wortking. The fundamental requirment for a GET is to be idempotent, you can call it as much as you want, you should not have any border effect (from the caller perspective) and the result should be the same. Do you see any example ? …GET http://xxx/yyy/Time which should return the current time. This is a very famous service…which can’t be deserved through a REST API.

So each time, someone tell you that REST fit all, just ask him to impelment a REST API that provide the current time…that does not fit.

I’m eprsonnaly enthousiast about REST, especially for the simplicity it brings, but it does not fit all !!

Sometimes important decisions are made in agreement because there is undetected misunderstanding which makes the decision fulfilling the requirement. Double check in this case is often useful.

I’m working currently on some modeling exercise. The question has been raised about the support for the model: UML or a real database? We agree (including me) on using the database. My understanding was that we will use a real database using the model as structure.

Finally we have a database with 3 tables: Entities, Relationships, Attributes … this is far from what I thought !!

Agile sounds on the decline … in the practice as mass adopte it wrongly. This is what are saying James Shore in this post,Jonathan Kohls in this post. I think the Agile bubble start to explose, the question is: will it follow the hype curve that I described in that post.