codrer

Aujourd'hui j'ai remis en route un vieux projet : Umiga - l'ancêtre de RainOS. Il est resté enfermé dans son archive 18 mois pendant que Rain prenait la relève. Durant cette période il m'était purement et simplement sorti de la tête. Petit choc en le redécouvrant.

Umiga 1.34

Le temps de retrouver le mot de passe root... le voici booté. Un beau et grand chantier, et pourtant... le truc inutilisable. Un paquebot trop lourd et donc inachevé. Ou inachevé car trop lourd...

Minimal Viable Product

Claque d'autant plus intense qu'en comparaison j'ai désormais RainOS. Même idée, même périmètre, même développeur. Mais une vie diamétralement opposée : 2 ans de travail sans horizon en vue d'un côté, et en face une première version réalisée en deux semaines pour être directement installée en production avant une évolution naturelle, fluide jusqu'à aujourd'hui.

Car RainOS a été fait en MVP : une version minimaliste avec un principe simple. Si le radeau flotte avec 3 planches, c'est suffisant pour le lancer à l'eau. On ajoute ensuite une voile avec une peau de chameau et on continue la route.

J'avais toujours bavé devant le principe, et effectivement quand un projet fonctionne en MVP, c'est magique. Littéralement. Tout devient simple, logique, sans effort, sans stress. Le radeau flotte, on test, on ajuste, et on construit au fil du trajet.

Solution ultime ?

Clairement, je suis fan.

Hélas certains projets - comme Backsic - ne peuvent pas être réduits à une version minimale, ils demandent un socle plus large, une architecture très difficile à découper en morceaux élémentaires.

Et c'est un contraste qui me fascine : pourquoi certains projets adorent le MVP, et d'autres le refusent ? Est-ce que cela dépend de la nature du projet ou juste un problème d'organisation, de ne pas trouver la bonne séquence ?

Cette question... c'est LA question. Je sens qu'elle va rester un moment...