C'est marrant, toutes les remarques qu'il fait me paraissent évidente mais il y a une très bonne raison a ça : je les ai toutes faites ! Que ce soit pour Univox (2-4-7) ou RacletteShare (1-3-4-6-7).
Mais je voudrais quand même revenir sur le point (4: "Over engineered") parce que je ne suis pas du tout d'accord avec sa conclusion.
Par 2 fois j'ai échoué à créer une boite, et les 2 fois j'ai passé trop de temps sur l'ingénierie. Devrais-je considérer que j'ai été trop soigneux, trop perfectionniste et que j'ai perdu mon temps à faire un truc trop propre ? La réponse est mille fois NON ! Du code n'est jamais trop propre, trop maintenable, trop bien testé …
Quelqu'un qui affirme qu'il a perdu du temps parce qu'il a voulu être trop soigneux et faire les choses trop bien se voile la face : il a perdu du temps parce qu'il n'était pas assez bon, pas assez bien organisé, et qu'il n'utilisait pas les bons outils.
Écrire du code clair, le faire évoluer au fur et à mesure qu'il vieilli, le tester convenablement, concevoir une architecture capable de passer à l'échelle, mettre en place un processus d'intégration continue, automatiser les déploiements … Voilà tout ce dont a BESOIN une boite qui vend du soft (y compris une application web ou mobile). Forcément pour un débutant ça demande énormément de travail et ça prend un temps fou, mais il n'y a pas 36 solutions :
1- développer en slip, à l'arrache en se concentrant sur l'aspect client/produit, avec 3 sous-options :
1.a- voir que ça n'intéresse personne, et arrêter le projet (sans avoir appris grand chose)
1.b- voir que ça intéresse des gens, mais se vautrer sur l’exécution (produit de qualité insuffisante) => pas appris grand chose non plus.
1.c- voir que ça intéresse des gens, arriver à susciter suffisamment d'enthousiasme pour lever des fonds et recruter des gens pour essayer de s'organiser correctement et remettre un peu d'ordre dans le bordel. (et subir la dette technique du début pendant de longs mois/années)
2- faire les trucs proprement, quitte à perdre du temps et planter sa boite : in-fine à la fin on a appri des trucs et on est plus compétent après qu'avant.
Pour moi les cas 1.a et 1.b sont une perte de temps et un véritable échec (surtout pour un ingénieur), tandis que le 1.c représente le meilleur destin possible pour un débutant, mais il faut vraiment avoir du bol, une idée incroyable et une équipe solide et convaincante pour les investisseurs.
Le cas 2 quant à lui est un échec du point de vue business, mais au moins du point de vue ingénieur c'est une vraie expérience et un vrai bonus en terme de compétence.