Dans mon précédent billet, Utilisez des frameworks, je préconise l’utilisation de frameworks au sein de sa solution au plus tôt dans la vie de la startup. Cela n’aura pas échappé à l’oeil aguerri de mon ancien padawan @lucascerdan qui m’a justement aidé l’an dernier à passer du MVP de Balloon en solution plus mature sous framework maison, puis sous Symfony2.
En effet, si je préconise l’utilisation de frameworks au plus tôt, c’est parce que justement je ne l’ai pas fait initialement pour des raisons inhérentes au contexte de la création de Balloon (longtemps sans coder, aventure startup non prévue / anticipée), mais aussi pour de bien mauvaises raisons, à qui aujourd’hui j’ai envie de tordre le cou..
Le MVP / proto de votre startup, ce n’est pas de la me*de
Ce n’est pas du code spaghetti, du dégueulis indigeste et désordonné dans le simple but de faire tenir un rideau de fumée à présenter à ses premiers utilisateurs / clients / investisseurs. L’argument qui ressort le plus souvent, “c’est plus rapide et plus flexible pour pivoter / réorienter son MVP“ ne tient tout simplement pas. C’est certes souvent plus rapide pour le premier jet de votre code et de votre projet, mais vous vous retrouverez alors avec un boulet que vous ne pourrez que difficilement trainer et faire bouger au grés de vos feedbacks utilisateurs. L’argument suivant, “je passerai ensuite sous framework une fois les besoins, le marché, le pricing et tout le reste validé avec mon MVP”, est très préjudiciable aussi, car c’est justement une fois tout ceci validé qu’il faut mettre la gomme et passer à la vitesse supérieure, en déroulant méthodiquement et implaquablement sur les bases de ce qui a été prouvé et construit précédemment.
(MVP = Minimum Viable Product = juste le nécessaire) != fourre-tout de features développé en 2 mois
Ce qui fait que vous allez valider votre positionnement, produit, marché, demande, c’est bel est bien le travail que vous mettrez dans votre MVP. Mais en ne sortant que le strict nécessaire, l’unique feature ou éventuellement la paire de features que vous pourrez sous deux mois soumettre aux premiers retours / feedbacks utilisateurs. Puis itérer là dessus.
Il est certes peut être un tantinet plus lent de se mettre / remettre en jambes dans un framework initialement, de définir correctement votre architecture initiale, de consigner le socle de vos développements dans des tests unitaires / fonctionnels, mais pour développer une feature simple et limitée, en y prenant grand soin, c’est amplement faisable. Justement, cette rigueur en temps limité vous permettra de ne pas vous égarer et d’ajouter une foule de tweaks inutiles, de vous concentrer uniquement sur le core de votre projet.
De même, à chaque retours clients / utilisateurs, il sera simplissime de modifier son MVP ou d’iterer sur le MVP suivant, grâce à la structure ordonnée, découplée, la rigueur DRY à laquelle vous vous serez astreinte dès le début, les tests unitaires vous servant de gardes-fous pour pouvoir aisément presque tout casser et tout reconstruire, tout refactorer sans crainte d’effets de bords sur ce qui aura déjà été accompli, et sans perde trop de de temps à tricoter et fixer d’insidieux bugs dû à cette extrème mobilité, bugs vous éloignant de votre objectif, efficacité, et rapidité d’itération.
Le cas idéal n’existe que rarement, MVP, bootstrap et lean
Voila les choix de raison d’après moi qui doivent vous pousser à vous astreindre à développer votre tout premier MVP dans une optique d’évolution mature et continue. Après, tout n’est pas rose et idéal, il se peut très probablement que votre MVP implique plusieurs features initiales complexes au lieu d’une seule simple, que votre première itération soit excessivement courte, que les demandes pressantes vous pousses à déroger temporairement à vos règles rigoureuses..
On maitrise rarement tout, et en effet l’objectif principal doit être votre vitesse d’execution, votre écoute utilisateur, votre capacité d’adaptation et de pivot. La technique doit être au service de cela, et non pas une entrave. Il est toujours bon d’avancer vite en étant au maximum possible rigoureux, puis refactorer rapidement et souvent, entre chaque itération, pour faciliter les développements ultérieurs.
Dans tous les cas, je pense qu’il ne faut pas sous-estimer la rigueur initiale techno de son MVP, la reléguer au dernier plan sous prétexte “qu’on a pas le temps”, “qu’on verra plus tard si ça marche”, “qu’il y a plein d’autres défis à relever en parallèle”. Certes, il faut savoir composer, et faire avec son contexte, son environnement, mais surtout, ne pas se méprendre et sous-estimer ceci au profit de tâches peut-être moins importantes.
Tout à fait d’accord !
L’architecture et les bonnes pratiques semblent “voler” un temps précieux sur les début mais apportent un confort et une rapidité incomparables au bout de quelques temps, quand on doit réagir vite pour répondre aux demandes des clients !
Après, il est clair que le temps de refactoring est extrêmement important au fil de l’évolution de notre connaissance du framework et des besoins du produit.
L’idéal est d’isoler les features les plus importantes et de se concentrer dessus afin de ne pas se disperser !
Tout à fait d’accord sur l’absolue nécessité d’utiliser un framework ! Cela parait tellement évident ! Un framework permet justement de passer le minimum de temps sur les fonctionnalités “sans valeur” comme la gestion des sessions et des utilisateurs, pour aller beaucoup plus vite aux fonctionnalités essentielles du MVP. Le framework c’est le meilleur moyen de faire du scaffolding et de montrer que “ça fonctionne vraiment” ! Et puis avec une pincée de Twitter Bootstrap ou de template ThemeForest, on peut vraiment aller très vite.
Après, sur la qualité du code, il y a un autre débat sur “jeter le prototype ou pas”, mais en tous cas, il faut refactorer souvent quoi qu’il arrive. Et découpler si possible.
Pingback: Ne vous souciez pas des performances de votre solution web (pensez-y juste) | I'm CTO bitch!
Pas complètement d’accord avec cet article. Je vais avoir du mal à expliquer pour quoi, c’est plus du resenti qu’autre chose…
D’abord, l’article part du principe qu’on va iterer sur le MVP pour arriver au produit fini, en gardant le framework. Mais qu’est-ce qu’un framework ? Dans le cadre de cet article je prends le terme comme désignant un framework Web “lourd”, “tout en un” type Django ou Rails, par opposition à des frameworks légers comme Flask ou Sinatra.
Une caractéristique de ces frameworks lourds est qu’ils encouragent à mon sens la conception d’applications monolithiques (ie. pas modulaires) dont l’architecture est cadrée par le framework. Par exemple, ils comprennent un ORM type ActiveRecord, s’appuient sur le pattern MVC, etc. Or, à mon sens, l’architecture d’une “application” (ou plutot du système) d’une startup devrait découler des besoins métier.
Au moment du MVP on ne connait en général pas suffisamment ces besoins pour faire les bons choix architecturaux, puisque le but est justement de comprendre “le métier”. Ce n’était pas forcément le cas de Balloon qui avait a priori vendu son MVP à des clients avant de commencer à coder ! Donc, on fait comme on peut et on aboutit forcément à un design bancal.
Dans cette phase-là je suis d’accord sur l’utilisation d’un framework s’il permet d’accélerer le time to market, mais *pas* pour la qualité du produit. Je considère presque qu’il *faut* coder de manière inmaintenable, pour s’obliger à jeter le MVP et repartir sur des bases saines.
Ensuite, avec une vision plus claire du résultat attendu, on peut passer à l’architecture. Si certaines parties du design correspondent à l’utilisation d’un framework (léger, en général…) autant ne pas s’en priver. On peut même utiliser *plusieurs* frameworks pour des briques différentes du produit (par exemple https://github.com/intridea/grape/ pour une API). Mais certaines parties ne rentreront peut-être pas dans le moule d’un framework et je n’essaierai pas de les y forcer.
Bon après, tout dépend de la conception de ce à quoi ressemble le “produit” d’une startup techno / Web. Quand on en parle comme d’une “application” on pense en général monolithique, et framework. Mais force est de constater que les startups qui grossissent, pour des raisons variées (flexibilité, scalabilité, maintenabilité…), évoluent en général vers du SOA.