Constat d’Echec

Il m’arrive de temps à autre de relever la tête afin de regarder où j’en suis. C’est ce que j’ai fait hier soir et c’est un constat d’échec qui s’impose :

L’application ne sera pas prête dans les temps pour une participation au concours de google.

Le plus décevant est de voir l’état d’avancée actuel du projet par rapport au temps passé dessus.

J’avais pu atteindre quelque chose de presque démontrable pour le concours SFR. Cela n’est absoluement pas le cas pour le concours google. La partie serveur et backoffice ont pris énormément de retard. Aucun développement n’a été effectué sur la partie mobile.

A l’origine de ce constat d’echec, de mauvaises décisions prises en amont que je vais essayer d’analyser ici. Je me remonte le moral en me disant qu’un bon plantage correctement analysé vaut bien 10 réussites chanceuses.

J’ai inclu trop de nouvelles technologies

J’ai confondu projet avec un objectif précis et projet boite de pétri pour tester des technologies nouvelles qui m’attirent.

En soit, tout le projet WYDW est une boite de pétri pour tester et apprendre à développer sous android. Mais petit à petit, c’est également devenu un projet réel dans lequel je voyais un objectif de plus en plus précis. J’aurai donc du avoir une approche plus pragmatique.

J’avais eu  beaucoup de chances au cours de la première itération du projet (jusqu’au concours SFR). J’avais inclu plusieurs technologies que je connaissais pas avec beaucoup de succès (Android, et une connectivité au serveur très légère grace au design Rest). Le tout m’avait permis de développer une partie serveur très rapidement. Mise à part pour android et rest, j’étais dans les technologies que je manipule au quotidien et mon efficacité fut optimale.

Pour la seconde itération, j’ai voulu essayer d’utiliser la nouvelle infrastructure de serveurs proposée par Google : L’appEngine. Cette infrastructure possède l’énorme avantage de fournir gratuitement (jusqu’à un certain niveau) des serveurs java du même type que ceux utilisés par google. Cette infrastructure permet de répondre aussi facilement à 1 requete/seconde qu’à 10000 requête/seconde. Elle permet aussi d’avoir beaucoup moins d’arrêts de service que mon petit serveur loué sur dedibox. Son développement semblait également assez facile et son couplage très facile avec GWT (une technologie frontale très adaptée au backoffice que je souhaitais également utiliser) avait fini de me convaincre de l’utiliser.

Utiliser L’appEngine fut la plus grosse erreur du projet

Essayer l’appEngine était logique. Mais je n’aurai pas du insister face aux implications que l’utilisation de ce service imposait sur le projet. Cela m’a imposé de purement et simplement recommencer la partie serveur à zéro. Pire encore, j’ai plusieurs fois eu l’illusion de toucher au but avec des coeurs d’applications qui fonctionnaient mais au final une contrainte supplémentaire m’imposait de tout changer.

Quand j’ai finalement réussi, la semaine dernière, à avoir un backoffice prometteur qui fonctionnait sur ma machine de développement je me suis apperçu que cela ne fonctionnait pas sur les serveurs de google et ne pourrait pas fonctionner. J’ai du à nouveau tout changer.

J’ai le sentiment d’avoir passé mes dernières semaines à jongler avec les problématiques imposées par l’appEngine. C’est un peu comme d’essayer de recouvrir une grande table avec une nappe trop petite. Vous arrivez près d’un bord, vous tirez la nappe et ca découvre l’autre coté de la table. Vous en faites le tour, vous tirez la nappe et vous découvrez à nouveau l’autre coté. Après de nombreux essais, vous arrivez à tourner la nappe de façon à ce qu’elle recouvre toute la table. Mais au moment d’installer la nappe sur la vrai table, vous vous appercevez que la vrai table n’a pas la même forme que celle sur laquelle vous vous êtes essayé un certain nombre de fois.

Il y a quelques succès :

GWT fonctionne à merveille. Il me permet d’avoir un frontal web qui ressemble à une application executée par le système. Voici un exemple qui fonctionnait avec le code d’il y a quelque semaines (une contrainte supplémentaire a cassé le tout.) Cet exemple n’a rien d’impressionnant. Il s’agit juste de l’implémentation des mockup balsamiq dont je parlais dans un billet précedent. J’étais très enthousiaste après avoir réalisé cela car le code sous jacent à cet exemple est très simple à comprendre et possède beaucoup de potentiel. Je pensais arriver très rapidement à développer le reste. C’était faux car une contrainte n’ayant rien à voir avec la partie GWT m’a bloqué par la suite.

J’ai également pu découvrir gson, et dozer. Deux librairies que je ne présenterais pas ici mais qui m’ont agréablement surprises et qui sont un succès à garder.

Je n’ai pas mis assez d’effort dans le recrutement

Le billet sur le recrutement sur le site n’avait servit à rien. (en mm temps personne ne visite ce site :-P ). J’en avais parlé sur twitter et mon post a été retwitté plusieurs fois. J’ai eu, suite à cette annonce, une vingtaines de visites inconnues sur le site. Pour recruter, j’ai surtout misé sur des gens de ma société de service (très portée sur les technos google) et j’ai effectivement eu une candidature interessée.

Après 3 semaines la personne n’avait toujours rien codé. Suite à une petite discussion il s’est avéré qu’elle preferait abandonner.

L’un des administateurs de Frandroid, un blog ayant plusieurs milliers de visites par jour, m’avais proposé de faire un post de recrutement sur frandroid. Je n’ai jamais saisi cette occasion et c’est un tord. J’aurai du.

De façon plus globale je me suis trop focalisé sur le développement et pas assez sur l’aspect managerial du projet.

Et maintenant ?

Même si le moral n’est pas vraiment là, je refuse de laisser partir en fumée tous les efforts que j’ai placés dans le développement de cette application. WYDW ne me rapportera toujours aucun copec, mais elle doit sortir pour que je puisse l’utiliser comme vitrine sur mon CV.

Coté développement, soit je continue à insister pour l’appEngine, soit je repasse sur mon ancien système et j’y ajoute GWT. Je pense que je vais choisir la deuxieme solution. Cela va engendrer des contraintes désagréables car GWT s’intègre assez mal à mon ancienne architecture, mais cela devrait avoir au moins l’avantage de fonctionner.

Changement de cap mon capitaine !