Perfectionnistes les entrepreneurs?
Je ne suis définitivement pas perfectionniste. Je fais du bon boulot, très bon même, mais la perfection, très peu pour moi. Pourquoi? Pas le temps. En y pensant, je me demandais si c’était juste moi ou bien la plupart des entrepreneurs ne sont pas perfectionnistes?
Attention, ce n’est pas parce qu’on est pas perfectionnistes qu’on fait du mauvais travail, au contraire. Par définition, le perfectionniste recherche la perfection de manière excessive. Et les excès, ce n’est jamais bon. Trop, c’est comme pas assez qu’ils disent…
Aussi, je ne parle pas de construire des ponts ou de faire une chirurgie au cœur. Je parle de résoudre des problèmes pour lesquelles il y a des solutions rapides et efficaces.
Au quotidien, je coupe souvent les coins ronds. Il y a des trucs qui ne sont pas fait comme on nous l’enseigne à l’école, dans les règles de l’art. Mais qui s’en soucie en autant que ça fonctionne? En développement Web, mes bases de données sont nickel et/ou top notch. Pas le choix, c’est le cœur de mes applications. Si ça a été fait en « broche à foin », c’est tout le système qui va en souffrir.
Par contre, sur la couche applicative, on s’en fout que ça soit de l’orienté objet mélangé avec un sac de spaghetti. De la belle programmation toute belle et toute propre, on a pas le temps pour ça. On garde le minimum, c’est-à-dire la logique optimisée, la performance et les commentaires. Le reste, et bien on s’en occupera quand on aura le temps.
Alors, le perfectionnisme, c’est une qualité nécessaire pour l’entrepreneuriat ou pas? Moi, je pense que c’est un clou dans le pied et un bâton dans les culottes. Je vois mal comment on peut résoudre des problèmes rapidement et efficacement en étant perfectionniste.
Qu’en pensez-vous?
Categorie: Articles - Réflexions, Entrepreneurship 9 comments »
Ta philosophie, ça marche jusqu’à temps que le client veuille changer de quoi dans l’interface. Là, ton programmeur va te dire: Ouin, mais c’est pas prévu pour ça va falloir tout refaire.
Si c’est pour un “one shot” en effet, on s’en calisse que ça soit du code spaghetti, tant que ça marche. La journée par contre que tu dois aller jouer la dedans, tu vas probablement dépenser plus de cash à corriger des bogues que si t’avais “bien” fait ça du premier coup.
Aussi, il y a une limite à “bien faire.
Moi, je vis avec mes contraintes. Si mon boss veut de quoi en peu de temps, ça va être tout croche, mais je m’Assure qu’il en est conscient et qu’il peut vivre avec sa décision. Rien de pire qu’un boss qui prend des mauvaises décisions sans s’en rendre compte!
héhéhé ne va pas penser que c’est broche à foin au point de ne pas se retrouver. Par exemple, un template pourrait être faire en tableaux html plutôt qu’en CSS. C’est le genre de truc qui se fait. On est des spécialistes du réutilisable pour éviter de perdre du temps plus tard héhé
En effet, c’est toujours les contraintes temps et argent qui donnent le tempo.
Au gouvernement vois-tu, on avait pas ces contraintes et tout était fait à la perfection. Impensable dans une PME.
Je crois que ça dépend de la vie utile de l’application. En programmation, on dit qu’une ligne de code passe 20% de son temps en création et 80% de son temps en maintenance.
Par contre, quand on fait des sites Web qui ont une durée de vie plutôt limitée vu la vitesse à laquelle ils évoluent, je peux comprendre ton point.
Si tes bases de données sont top notch comme tu dis, alors pourquoi tes objets ne le seraient pas également? Pourquoi ne pas favoriser un environnement de développement favorisant le développement rapide d’applications. Je pense à des plateformes MVC par exemple ou simplement de bien séparer sémantiquement les portions de code pour pouvoir s’y retrouver. Souvent, un simple standard de programmation spécifiant une nomenclature de nom et une suggérant une certaine indentation des éléments dans le code pour assurer rune bonne lisibilité peut suffire.
Je suis tout de même d’accord avec toi sur le fait que dans un contexte de PME, on ne peut pas se permettre de gosser sur des petits détails. Par contre, la qualité ne doit pas être affectée. À mon avis, vaut mieux livrer en retard quelque chose de qualité que de livrer à temps quelque chose avec des bogues.
Étant un, jeune entrepreneur et certainement perfectionniste comme tu le décris, je pense que c’est important. Quand on commence une application pour la revendre il est évident qu’il faut bien la commencer. Quand je pense surtout au long terme. Je ne sais pas pour toi, mais moi il est évident qu’un jour au l’autre je vais devoir prendre des développeurs pour continuer l’application et me concentrer sur quelque chose d’autre.
Alors, il est normal que je sois très perfectionniste pour que quand je vais laisser mon boulot à d’autres ils ne doivent pas me dire qu’il faut tout refaire.
Et pour te dire, j’ai bien souvent vécu cela dans les différentes boites où j’étais. Et, ça coute cher de faire les choses un peu à la va-vite.
Hum… Je n’ai peut-être pas été assez clair. Je ne livre pas des projets avec des bogues ou qui ferait peur à un zombie. La qualité est très importante. Comme Guillaume le dit, on utilise le MVC pour développer, mais on ne polit pas notre code avec une lime à ongle pour que ça serve de cas d’études dans un cours de beauté informatique. C’est plus ça que je veux dire!
Personne ne s’est jamais plains de mon travail comme client ni comme collègue.
Par exemple, si une requête SQL s’éxécute en 0.2 secondes et que c’est suffisant pour ce traitement, je ne pousserai pas plus loin pour rien. Mais pour un truc comme Percute Analytique, je vais trouver inacceptable de traiter 50 M de données en plus de 2 secondes et creuser jusqu’à ce que ça prenne moins de 1 seconde.
Hello, Stéph,
je suis moi aussi entrepreneur, et je me reconais bien dans ce que tu dis: le questionnement permanent du “qu ‘est-ce qui est vraiment essentiel”?
Inversement, les autres n”ont évidemment pas forcément tort..
Le tout est de savoir si tout le monde parle de la même chose. Dès qu’on reste au niveau de la généralité, chacun comprend ce qu’il veut. Tu donnerais un rien de complément, avec UN concret et détaillé, et je pense que tout le monde pourrait se rapprocher.
En tant que programmeur:
“Par contre, sur la couche applicative, on s’en fout que ça soit de l’orienté objet mélangé avec un sac de spaghetti. De la belle programmation toute belle et toute propre, on a pas le temps pour ça. On garde le minimum, c’est-à-dire la logique optimisée, la performance et les commentaires. Le reste, et bien on s’en occupera quand on aura le temps.”
C’est vraiment clair que le code spaghetti napporte aucun bénéfice a une application … mais par contre, si ca te convient pour l’instant, pourquoi pas … comme tu dits tu rajusteras plus tard … pour ma part je design avec le UML avant sans y perdre un temps faramineux … mais tout de meme pour que mon code soit bien modélisé et pour facilité les ajouts futurs … jmodélise moi meme mes bases de données mais j’ai 3 DBA qui s’occupe d’optimiser mes Query … index etc etc ..
Vois-tu, on fait nos projets en orienté objet et on modélise souvent avec UML. Par contre, on ne perdra pas de temps avec les beaux dessins dans les beaux documents. Des brouillons sur un tableau avec un marqueur fait souvent la job pour enligner l’équipe!
Dans ce cas, je juis d’accord
Vive les white board !