oui
Oui. Ajouter de nouvelles fonctionnalités c’est facile au début. Ajouter de nouvelles fonctionnalités rapidement sur une code base conséquente pour laquelle on a beaucoup de dette technique, c’est extrêmement compliqué.

Je fais souvent la comparaison entre le code et la cuisine d’un restaurant. Lorsque les commis ou les chefs font quelque chose, ils passent leur temps à nettoyer leur plan de travail. On prépare une viande ? On nettoie ensuite immédiatement son plan de travail. On émince des oignons ? On nettoie son plan de travail, etc. C’est la seule façon pour faire en sorte de pouvoir accueillir des coups de bourre en provenance de la salle sans caler. La plupart des code bases de notre industrie ressemblent plutôt à des cuisines dégueulasses au sein desquelles personne ne nettoie vraiment jamais. L’évier est plein de vaisselles sales, tout comme le plan de travail et la table aux alentours, jonchée de détritus et de plats qui pourrissent.

Rajouter une fonctionnalité dans ce foutoir (i.e.: faire à manger), ça correspond à chercher tout d’abord votre gros couteau et votre planche à découper dans ce bordel. On va y passer 10 grosses minutes pour finalement retrouver le couteau collé entre 2 poêles amassée au fond de l’évier (où il aura d’abord fallu ressortir toutes les casseroles sales), nettoyer le plan de travail pour y trouver un coin de libre pour y poser sa planche, commencer à faire sa préparation, vider tout l’évier pour pouvoir y faire la vaisselle indispensable pour le plat, etc.

La qualité (et les refactoring constants) c’est quelque chose d’indispensable pour ne pas se retrouver dans une situation où pour ajouter la moindre fonctionnalité, on doivent au préalable faire tout ce travail préparatoire. On n’a même pas commencé qu’on a déjà une demie journée de rangement à faire avant. La bonne stratégie pour moi est : on rajoute une feature ? On nettoie son code. On rajoute une nouvelle feature ? On nettoie son code (Ad lib)

Il faut pouvoir faire de temps en temps des compromis sur la qualité dans des cas très circonstanciés et avant d’y remédier dans un second temps, mais le quick and dirty comme stratégie de base est une fausse bonne idée. Cela semble à priori être une stratégie pertinente pour aller très vite au début, mais le début ne dure pas longtemps. Et vous irez très vite plus lentement (oui, bizarre cette phrase ;-)

La dette technique vous rattrape beaucoup plus rapidement que vous ne l’avez imaginé, vous mettant dans une situation embarrassante et frustrante pour les devs qui restent : pourquoi n’arrivons-nous plus à avancer aussi vite qu’auparavant ?

Et puis vous n’arriverez pas à conserver vos bons éléments très longtemps… Notre code base est notre cuisine. Qui a envie de travailler dans une cuisine aussi dégueulasse et peu fonctionnelle très longtemps ?

C’est clair que dans un tel merdier, impossible de recevoir de nouveaux convives pour faire la fête.

thomas-pierrain

114

non
Si la qualité de code n'est pas intrinsèquement incompatible avec le mode startup, plusieurs éléments font qu'en général, cela n'est effectivement pas le cas. Donc je vote non.

Tout d'abord, la qualité de code nécessite de l'expérience. Or, de nombreuses startup embauchent souvent des profils jeunes, c'est-à-dire pas ou peu expérimentés. De nombreuses raisons à cela, la première étant sans doute financière. Mais rien que ce sujet mériterait un article complet !

Ensuite, la rémunération est généralement plus faible au sein d'une startup que dans une entreprise "classique" (c'est pas moi qui le dis, c'est l'INSEE !). Difficile dans ce cadre de rémunérer de bons développeurs, surtout qu'on manque généralement de profils confirmés/séniors.

De plus, la vision "réactive" incite à adopter des approches dites agiles. Rien de mal à cela, (au contraire), mais il faut rester agile dans l'application même des méthodes agiles. J'ai trop souvent vu des comportements du style : il faut que je finisse vite ce truc pour pouvoir terminer mon sprint, et donc je code une solution à l'arrache. La fonctionnalité avant la qualité.

Enfin, le côté polyvalent est aussi un frein. Difficile à mon sens de savoir tout faire et de le faire bien. Difficile de travailler sur un logiciel mode SAAS par exemple, tout en s'occupant du site vitrine, de la newsletter et des réseaux sociaux.

Quand on voit déjà la difficulté d'avoir du code de qualité en général, lorsqu'on s'impose des contraintes supplémentaires, cela me parait encore plus difficile.

Voilà donc pour résumer, la réponse aux questions posées :
- la qualité de code est-elle compatible avec le mode startup : en théorie oui, en pratique elle n'est pas vraiment favorisée
- peut-on faire du code de qualité en mode startup : bien sûr (comme partout), encore faut-il avoir les compétences nécessaires en interne (plus difficile et plus rare que dans une entreprise "normale")

Du coup, je vote non car bien que pas incompatible en soi, elle n'est pas favorisée (je pense même qu'elle est défavorisée). C'est loin d'être une fatalité, surtout quand on voit déjà le manque de qualité de code en général, (qui n'est donc pas une caractéristique intrinsèque du mode startup).

Après, tout cela reste également subjectif, puisqu'il faudrait définir ce qu'on entend exactement par startup (il n'est malheureusement pas rare de voir que beaucoup considère que startup se limite à être une jeune entreprise en oubliant le coté innovant et/ou à fort potentielle de croissance) et aussi ce que l'on entend par code de qualité (pour moi, au minimum TDD et SOLID, avec un gros plus pour des approches complémentaires comme CI/CD)

francois

09

oui
Non ce n'est pas une fatalité. Mon expérience avec les start-up est malheureusement tout le temps la même. La qualité a été mise de côté jusqu'au moment où l'application ayant grossie, les Bug s'enchaînent, l'équipe n'arrive plus à délivrer et tout le monde se barre.

Dans les faits on ne va pas plus vite en négligeant la qualité, je dirai même que c'est la qualité qui te permet d'être réactif et de changer de cap techniquement très rapidement. A mon sens c'est la meilleure alliée des start-up. Elle garantie vitesse de livraison, évolutivité et durabilité.

Le problème c'est qu'il faut encore avoir des développeurs qui ont les bonnes compétences. C'est surtout là, qu'est le problème.

gecedric

06

non
Difficile de réagir aux diverses nouveautés très rapidement tout en livrant du code de qualité. Souvent (trop souvent), on privilégie la rapidité de livraison pour faire avancer l'entreprise et remporter un nouveau marché au détriment de la qualité du code produit.

Il serait alors possible de prendre le temps en suivant pour reprendre la feature et la cleaner mais les dévs sont déjà repartis sur une nouvelle feature à sortir en urgence pour une nouvelle démo très importante.

Une orientation vers des "features switch off" permet d'isoler plus facilement ces développements mais le clean du code reste tout de même à faire et avec le peu de ressources et/ou le manque d'expérience...

Bref, ce n'est pas vraiment incompatible mais je réponds non car les préoccupations sont plutôt centrées sur la quantité au détriment de la qualité.

le8ejumeau

02

oui
Ben Sonar sort du mode startup pour passer en scale up et on a une base de code de qualité depuis 14 ans et ça marche : clean as you code. Faire de la non qualité c'est se tromper d'investissement...

nicolas-peru

14

non
Evidemment non. En mode startup tu augmentes la vitesse de delivery à son paroxysme. Tu as besoin aussi de features pour avoir des choses à montrer. Il te reste donc la dernière variable d'ajustement, la qualité, à réduire pour tenir les 2 autres objectifs.

Grâce à cet investissement sous forme de dette technique, tu gagnes des clients et des parts de marché qui te font vivre. Tu peux alors rembourser la dette, mais rien ne t'empêche de continuer à t'endetter techniquement encore + en continuant à délivrer vite des features au détriment de la qualité pour ramener encore + de clients. A toi de choisir le bon moment pour rembourser.

anhvutran1

34

oui
Rogner sur la qualité c’est se priver d’avenir. Par exemples : difficulté à remplacer facilement des pans de code (suite à un pivot par exemple) ou encore difficulté à intégrer rapidement de nouveaux équipiers en cas de scale up

matremy

24

non
Le "mode startup" est un terme trop vague pour pouvoir répondre à cette question par autre chose que "oui ET non".

Dans la phase d'innovation où l'on cherche encore son produit et son modèle économique, il faut faire des prototypes jetables. Je dirais même que ce n'est pas la qualité du code qui compte mais la quantité : il vaut mieux avoir peu de code voire pas du tout. Les outils NoCode/LowCode sont très pertinents à ce stade.

bartlettstarman

01

oui
En start-up, les choses doivent être livrées vite, c'est vrai. Mais s'il faut les livrer aussi vite, c'est parfois parce que le besoin n'est pas 100% identifié. Il faut donc itérer, et ce qu'on va livrer vite pour l'itération en cours va souvent remettre en question ce qui a été livré aux itérations précédentes. Et, en start-up comme ailleurs, quand on doit modifier du code existant, c'est bien plus rapide de le faire quand le code est facile à lire, comprendre et modifier. Bref, quand il est clean!

C'est pourquoi, je dirais même qu'il est encore plus important d'avoir du code de qualité en start-up, pour garantir que le code peut évoluer à une vitesse constante et suivre les évolutions nécessaires pour trouver notre product-market fit, et poser des bases solides pour créer le produit qui nous fera passer au rang de scale-up!

edouard-mangel

13

non
Cela dépend de la culture d'entreprise plus que du mode Startup ou non à mon sens.

En effet, si la qualité du code n'est pas un élément identifié comme étant "non négociable" certaines startups adoptent donc un mode de delivery orienté "Time-to-market" ou "Business-First" voir "POC-First", le contenu du sprint étant alors conditionnés aux deadlines et autres joyeusetés.

Ce dernier point m'apparait comme point central: il peut alors laisser peu de temps aux devs pour s'approprier le fonctionnel, le comprendre, l'enrichir et le discuter.

Pis, ce mode entraîne aussi des contexts switchs fréquents, voir, des transgressions entre les contextes d'équipes menant à une dilution du savoir produit. Cela sans aborder les compromissions sur la qualité en mode "C'est un MVP", "On reviendra dessus plus tard" (sans que ce soit jamais le cas), etc...

Second point, ce mode de travail parait adapté à de "petites équipes tech" (~10/20/30 personnes max.) qui peuvent avoir le temps de dialoguer et de construire de la connaissance produit, afin que chacun soit garant de la qualité.

Aussi, après des phases d'hyper-scaling, nombreuses sont les entreprises qui ratent leur transformation: on tente de conserver un mode startup en ayant multiplié la taille des équipes, sans avoir pris le temps de redécouper clairement les responsabilités codebase ou métier, ce qui par effet papillon peut complètement détruire l'ownership d'une équipe sur un code, diluant encore une fois la qualité au profit de la delivery.

Enfin, l'organisation du backlog devient un sujet majeur pour la tenue du code: si les priorités des moirs à venirs sont définis trop tardivement (comprendre, trop près de leur réalisation) cela ne laisse pas le temps aux équipes techs d'échanger et de challenger les besoins dans de bonnes conditions. C'est notamment vrai lorsque l'on adopte une orientation PM-only, proche du besoin business, sans passer par la case PO, avec un backlog priorisé, qui permet à l'ensemble des équipes responsables d'un groupe de fonctionnalité de se synchroniser, afin de ne pas démultiplier les approches et la complexité tout en conservant une "vision produit" compatible avec les choix d'architectures adoptés.

Il existe bien évidemment des situations ou certaines entreprises parviennent à conserver une qualité de code correcte en mode startup, mais de mon point de vue cela ne représente pas la majorité des situations que j'ai pu vivre.

Pour toutes ces raisons je vote donc NON.

th3rulxt

00

oui
Oui, et pour différentes raisons:
* Faire de la non-qualité fait rarement gagner du temps (sauf pour une feature one-shot qu'on va jeter le lendemain)
* Ca rend la start-up plus attractive auprès des développeurs et développeuses.
* Ca nous permet de rester flexible et évolutif, de pouvoir ajouter de la valeur sans être freiné par notre code
* La culture du rush et de la non-qualité n'est pas viable sur la durée. Ca sera éphémère.
* Quand on est à taille humaine, on a un contexte favorable pour être autonome sur nos pratiques et choix techniques, et en discuter facilement ensemble. Autant en profiter ?
* En start-up ou ailleurs, faire du code de qualité s'apprend, et requiert un investissement pour se former et monter en compétences. Ce n'est donc plus facile en soi, bien que partir d'une base de code souvent plus petite lève certaines contraintes qu'on pourrait avoir ailleurs.
* Parce que c'est quand même plus sympa de se lever chaque matin et d'avoir le sentiment qu'on fait notre travail proprement :)

Donc oui c'est compatible, mais non ce n'est pas toujours évident, ça ne coule pas de source, pour les raisons évoquées en haut de page (pressions, ...)

cedric-teyton

02

non
"On bosse en mode MVP !", "On fera de la refacto plus tard, là faut délivrer de la valeur !", "Non désolé, on a une deadline pour les commerciaux dans 2 semaines, on peut pas se permettre de ..."

favouille

00

oui
Si elle est automatisée et en continue c'est un excellent moyen d'améliorer son code en continue avant de merger et de se prémunir de futur problème.
C'est aussi un moyen de présenter de jolies métriques de progression à ses investisseurs

ph-charriere

12

non
Oui on peut mais si on est certain de ce qu'on veut en sortie tant d'un point technique que fonctionnel. Et c'est rarement le cas en startup.
Donc la question pour moi c'est plutôt "est-ce que ça a un intérêt?"

christophe-havard

00

oui
Une startup est souvent amené à pivoter et à se réinventer. Ce qui techniquement t’amène a remodeler ton code. Le faire avec du code de qualité et tester est bien plus simple

etienne-pierrot

12

non
L’objectif d’une startup est de lever des fonds nécessaires à devenir autre chose qu’une startup justement. Le logiciel développé initialement a donc un objectif court termes dont la qualité du code n’est pas utile : et ce qui n’est pas utile n’est pas implémenté.

dragonfitz

00

oui
Oui, la non-qualité de code peut tuer une startup. A la startup de trouver le curseur pour avoir un code/produit durable ( grâce à un niveau suffisant de qualité )

nicolas-mingo

01

non
Je ne peux pas répondre d'expérience, mais j'ai l'impression que ce n'est pas compatible.
Une startups doit pouvoir fournir un POC très rapidement et le mettre sur le marché alors qu'en générale, faire de la qualité, ça prend du temps de réflexion supplémentaire.
J'ai déjà entendu dire que ça fonctionnait par phase : dans un premier temps, une équipe de développement s'attarde à mettre en place un produit qui fonctionne pour 80% des cas et dans une seconde phase, lorsque le produit à fait ses preuves sur le marché, l'équipe de développement se scinde en 2 : une équipe pour remettre le produit au propre afin qu'il survive au long terme et une équipe qui s'occupe à avancer sur les nouveautés afin de montrer des trucs intéressant à de futurs investisseurs.
Mais bon, j'ai jamais participé à la construction d'une start-up donc j'ai surement loupé des étapes et mal compris des trucs...

benjamin-lemin

00

oui
OUI mais...

...il faut que les développeurs de l'équipe soient tous aguerris des bonnes pratiques, ou en tout cas être mentorés par un tech lead qui saura amener les pratiques de manière pragmatiques.

Si les bonnes pratiques sont là, alors elles vont tout à fait dans le sens de l'agilité.

On peut repousser les choix trop technique bloquants à plus tard, et valider rapidement un concept, tout en ne créant pas une montagne de dette technique qu'il faudra payer plus tard à la place d'ajouter de nouvelles fonctionnalités.

pierrecriulanscy

01

non
Il faut mettre des bases solides et maîtriser la dette technique.

aboukratyossef

10

oui
La qualité de code et la delivry ne sont pas antagonistes, ça demande une culture du développement particulière. Faire vite n'est pas une excuse pour faire sale, le respect de soi passe aussi par ce que l'on produit.

gaetan-eleouet

01

non
Compatible : NON, en effet cela fait "perdre" du temps à très court terme (le résultat est plus qualitatif, mais à ce moment là, la ressource la plus précieuse est le temps)

Indispensable : OUI, pour ne pas perdre le peu de temps que vous avez voulu économiser précédemment et maintenir une courbe de productivité le moins horizontale possible

Tout dépend donc de l'échéance à laquelle vous comptez revendre votre startup.

je vote donc non à contre coeur ;(

fouquepascal

10

oui
Certaines abstractions permettent d'adresser plus efficacement l'incertitude. L'objectif doit être d'éviter les coûts de refactoring et des migrations de données, lorsqu'on va inévitablement rectifier le tir niveau produit.

Je pense au découplage des différents domaines du métier. Si on doit revoir totalement la logique d'un contexte, pas forcément besoin de toucher aux autres.

Je pense aussi à l'event sourcing, qui permet d'avoir une source de vérité encodé sous la forme d'événements, séparée des tables de données destinées aux vues. Un changement du modèle de données des vues ne nécessite pas de script de migration, puisqu'on peut régénérer les données à partir de l'historique.

pad

01

oui
"Mettre en prod permet de rentrer sur le marché.
La qualité permet d'y rester.
-- Nicoals Fédou, FlowCon 2018"

Pour avoir travaillé dans une cellule "Innovation", on s'est rendu compte que travailler en TDD, en full pair-programming nous permettait de :
- livrer plus vite
- pas être bloqué par les absences des uns ou des autres
- être plus réactifs face aux changement des demandes produit

fabien-hiegel

01

oui
Chaque fois que j'ai voulu faire du code sans test, le temps de développement a pris énormément de retard.
Ajouter une fonctionnalité dans un code spaghetti, c'est joué à Jenga. Comme dans le jeu, à un moment tout s'écroule.
Ces seuls arguments suffisent pour prendre en compte la qualité. Se dire "on fera propre plus tard" revient aux TODOS qu'on ne corrigera jamais.

alexandre

01

oui
OUI
La définition de qualité est variable dans le temps et contextuelle.
En d’autres termes, une startup, comme les autres entreprises se doit de faire des choix en terme d’investissement et des arbitrages conscients.
Il faut donc définir ce qu’est la qualité dans chaque contexte et être en capacité de produire du code de qualité ou de favoriser la vélocité et le refactoring incremental afin d’éviter la sous-qualité et complexité accidentelle voir systémique

christian-klat

01

oui
Des raccourcis peuvent être pris pour livrer de la valeur rapidement et obtenir un MVP utilisable : utiliser des services existants, faire des actions manuellement, faire des prototypes réactifs, etc. La réponse à un problème n'est pas toujours de produire du code mais produire de la valeur.
Le code créé lui ne doit pas se couper de principes de base de clean code (SRP, réutilisable, simple, etc.). Si je devais redémarrer ma startup à 0, j'écrirais bien moins de code que ce qu'on a produit. Je me concentrerais sur les fonctionnalités clés pour les clients et je les développerais en TDD afin qu'elles puissent avoir une réelle valeur pour notre startup : qu'elles puissent évoluer rapidement en fonction des retours des clients.

Si le code créé va rester dans le coeur du produit, il ne devrait JAMAIS être produit sans tests et sans suivre des principes de base du Clean Code.

arthur-magne

01

oui
Oui, car la survie de la startup dépend de la facilité à pivoter et ajouter des fonctionnalités sans bugs et donc sans nuire à sa réputation naissante.

miiitch

01

oui
Ce que j'ai constaté en tant que CTO d'une agence: une startup ou il y a un founder non-tech (ou alors un binôme non tech) et 1 des 2 choses qui se passent : on recrute un lead dev avec 2 ans d'xp qui va devenir notre future CTO ou alors on engage des freelances / une boite offshore pour sortir notre 1er produit. La qualité dans ces conditions n'est pas garantie. Ensuite une boîte comme ça cherche quelqu'un pour aider à sauver / refaire le projet...

Mais une startup avec un co-founder tech, qui a de l'experience, qui a déjà géré une équipe, scalé un projet etc? Oui, la qualité peut être là, même si les moyens sont limités!

marekk

01

oui
C'est justement parce qu'il faut sans cesse s'adapter, changer de cap et saisir les opportunités qu'il faut absolument mettre la qualité au sein de tous les process.
Mais attention il faut différencier qualité et complexité, en mode start up la simplicité est maître mot, pas besoin d'architecture ultra complexe, d'events sourcing ou que sais-je avant d'avoir stabilisé son model économique !

younas

01

oui
pas de qualité de code + bouger très vite = désastre en peu d'itérations

fab

01

oui
Oui, il faut décorréler le prototypage (code qui devra être réfactoré), du code production qui se doit de répondre à des exigences de qualité.

valentinbesse

01

oui
C'est une fatalité oui, il ne faut PAS monter une startup avec une mauvaise base de code.
La qualité de code n'est pas seulement compatible, elle est essentielle. Si on veut bouger vite il faut une base de code saine que l'on peut facilement retravailler.

gervaisb-battle

01

oui
Je pense que oui, un code de "qualite" ( terme tres generique ) est pour moi un code qui permet une iteration rapide et reduisant les risques de regression.
Avec des tests, un code "clair", decouper pour supporter une certaines variation et avec une suite de test dont on a confiance, on peut au final avancer bien plus vite a mon avis que si l'on mets ces considerations de coter.

platel-kevin

01

oui
La qualité n’a pas de lien systématique avec le type d’entreprise. Une multinationale peut forcer à faire de la non qualité. Une startup dans la finance peut au contraire blinder la qualité car elle a des contraintes légales à respecter et l’impact d’un bug peut être financièrement énorme.

guillaumel

11

oui
Faire du code de qualité est une compétence à acquérir par le développeur. Quand elle est acquise, il devient difficile pour lui de développer sans 🙃
Ce n’est donc pas un problème startup ou pas startup mais plutôt de recrutement et formation.

benoit-prioux

11

oui
Pour ma part si une start up ne fait pas du clean code, elle restera une start up.
Le clean code ne prend pas forcément plus de temps quand on s'organise correctement et qu'on donne juste un pourcentage du temps dédier à cleaner et réorganiser le code.
Si on est malin on peut utiliser les nombreuse étapes qui n'ont pas besoin d'un développeur pour cleaner le code et s'organiser, comme le temps de QA ou de rédaction de spécification ou encore l'affinage.
Plusieurs réunion ou il y a beaucoup de développeur peuvent être aussi efficace avec la moitié, l'autre moitié peut pendant ce moment penser à l'architecture ou cleaner du code.

lionel-meunier

00

oui
biensur car startup ne veut pas toujours dire que lon veut tout au plus vite. si le livrable est suffisamment découpé si et seulement si le métier est près à faire des concession soit sur la date ou sur le contenu du livrable. sinon c'est hardcore. Au passage bise à toi. Jeremy Lebair

lebair-jeremy

00

oui
Une start-up est censé être agile, pouvoir tester rapidement/souvent une idée ayant de la Valeur pour recevoir le maximum de feedbacks(un Incrément étant à chaque itération dans un état utilisable et potentiellement livrable ce qui est incompatible avec une dette technique élevée).
En Agile, ce qui n'est pas négociable, c'est la qualité(excellence technique).

ibmdiouf

00

oui
Concrètement dans une optique de scaleup je pense qu'avoir une qualité dans le code est important. Elle n'est pas à négliger car elle permet aux futurs employé d'être rapidement efficace car la compréhension se fait bien plus naturellement que dans du spaghetti code par exemple.

james-clerc

00

oui
Je dirais presque que la qualité, c'est ce qui va faire la différence entre les startups qui survivent et celles qui s'effondrent. Pour répondre rapidement à un marché mouvant/balbutiant, une startup va probablement devoir contracter une forme de dette, mais contrairement à ce que beaucoup pensent, la dette ce n'est pas sabrer la qualité, les deux sont à dissocier!

coudert-sylvain

00

oui
C'est toujours possible. Mais il faut une équipe technique forte qui ne cède rien quand on demande de faire du "quick and dirty". Il faut toujours faire comprendre et rappeler que les quelques heures gagnées ici seront largement perdues plus loin et qu'une app/site de qualité impressionnera toujours plus qu'un produit bancale aura planté en démo.

julien-3

00

oui
Si tu mises pas sur la qualité tu passeras plus de temps à expliquer ton code crade aux nouveaux devs plutôt qu'à prendre le temps de justement écrire du code de qualité. Et puis travailler sur du code spaghetti ça motive personne. Or le but d'une startup c'est en général de croître et donc d'être productif.

comte-florian

00

oui
Dans le monde du dev. le seul moyen d'aller vraiment vite, c'est de faire vraiment bien !

damon-colin

00

oui
The only way to go far is to go well

sfaxi-med-amine

00

oui
S'asseoir sur la qualité, c'est s'asseoir sur le domaine, c'est oublié ce que l'on produit et pourquoi on le fait.
Ne pas confondre vitesse et précipitation.
Ce que l'on attend d'un artisan, c'est un travail rendu et de qualité, pas quelque chose que l'on doit sans cesse refaire ou passer son temps à corriger.

bertrand-bougon

00

oui
Une app qui bugue, c’est un prospect qui ne reviendra plus jamais, voire fera de la mauvaise publicité.
Penser carpaccio afin que la qualité soit toujours au top.

david-boissier

00

oui
Je pense que oui mais cela coûte beaucoup plus cher que du “Quickn’dirty” car en plus de demander des développeurs et développeuses avec une expérience plus conséquente que ce que l’on trouve en général au démarrage d’une startup, il faut aussi une vision produit clair… En bref, oui mais cela demande plus de moyens au départ. Ce que je trouve bizarre, c’est de démarrer une startup, sans investir dans la qualité de son code, ni prevoir (avec une VRAI phase d’investissement) de le faire plus tard…

aly-bocar-cisse

00

oui
Si on fait l'impasse sur la qualité du code, on va réussir à livrer rapidement pendant une courte période jusqu'à l'émergence du monstre spaghetti qui va venir détruire la vélocité et le moral de l'équipe.

mathieu-barberot

00

oui
The only way to go fast is to go well. Uncle Bob

twitter.com/...

houcem-naffati

00

oui
"The only way to go fast is to go well" Uncle Bob

gpicavet

00

oui
Pour moi, il faut mettre de la qualite au niveau de la core feature ou ce qu'elle deviendra. Ensuite, on peut mettre la qualite au niveau des outils et des librairies qui vont nous permettre de coder plus rapidement et de tester plus rapidement les hypotheses.

Donc la reponse est : oui, meme dans une startup, il faut mettre de la qualite ;-)

maxime-sahroui

00