Quel type de méthode de programmation préférez-vous? Succès vs liberté

Question

Préféreriez-vous avoir une totale liberté sur toutes vos techniques de développement ou préférez-vous suivre une approche plus sûre, plus ennuyeuse, qui offre une chance bien meilleure de travailler à la fin? Hacker vs ingénieur? Peintre vs électricien?

Answer 1

J'aime faire avancer les choses. Cela signifie utiliser des outils de développement établis et un processus raisonnable, tout en faisant preuve de créativité dans le cadre de ce processus. La plus grande poésie de la langue anglaise a été écrite selon des règles strictes en matière de métrique et de comptine, et semble néanmoins créative pour elle.

Answer 2

La "liberté ou rien" L’attitude est juvénile et agaçante, le monde réel ne fonctionne pas de cette façon.

Donnez-moi le processus établi.

Answer 3

Économiste. Si cela me rapporte de l’argent et que cela n’est pas contraire à l’éthique, je suis pour.

Answer 4

Cela dépend si vous êtes intelligent.

Si vous êtes intelligent, alors la liberté. Vous ferez votre propre succès.

Mais le problème est que personne ne peut dire honnêtement s’ils sont eux-mêmes intelligents.

Answer 5

Je ne pense pas que la liberté vs ennuyeux est valide. Un processus léger défini qui est également flexible est certainement faisable. Tant que personne ne me montrera qu’il est un adepte du développement, je ne permettrai probablement pas autant de liberté.

Suivre un processus lourd et inélastique peut également être préjudiciable.

Il faut beaucoup de bon sens, mais c’est une chose difficile, qui varie selon les développeurs et les organisations. Il n’existe pas de solution unique.

Answer 6

Personnellement, je préfère la liberté d’essayer de nouvelles idées, de nouvelles techniques, de nouveaux procédés, mais je pense que cela devrait être autorégulé. C’est-à-dire que je pense que les techniques, les processus, etc. doivent faire leurs preuves. Exiger la liberté d'expression personnelle dans un environnement d'équipe n'est probablement pas un bon moyen de renforcer l'équipe, mais je pense que l'équipe doit être ouverte à l'amélioration par le biais de nouvelles idées. Une fois que l’équipe a adopté un processus / une technique, il serait contre-productif de continuer à insister sur votre propre voie (même si elle est meilleure) si l’équipe ne la voit pas de la même façon que vous.

Answer 7

Ce n'est pas une question valide. Vous pouvez exercer votre liberté de suivre un processus ou vous pouvez exercer votre liberté de ne pas suivre un processus. Que vous suiviez un processus ou non, vous avez toujours la liberté.

Answer 8

C'est une fausse dichotomie. Le processus imposé ne correspond pas au succès. Par exemple, dans les compagnies de téléphone, les développeurs de logiciels sont soumis à une énorme quantité de processus (lecture naïve du développement "en cascade"), ce qui fait perdre beaucoup de temps à la rédaction de documents de conception détaillés, puis lorsque le logiciel est livré, les clients découvrez que ce qu'ils ont demandé n'est pas ce qu'ils voulaient. À ce stade, les ressources sont presque épuisées et tout le monde y perd. Le processus imposé tue les projets.

D’autre part, lorsque Amitabh Srivastava a imposé à l’équipe Windows des exigences de base en matière d’analyses et de tests, le taux de bogues a diminué et, au moins chez mes amis de Microsoft, la productivité et le moral ont été améliorés. Je suppose que quelque chose de similaire s'est produit dans le projet KDE quand ils ont commencé à obliger tout le monde à utiliser valgrind . Du coup, plus d’erreurs de mémoire et de dumps déroutants.

En général, j'estime qu'il est plus efficace d'imposer des outils utiles que d'imposer des processus . Les preuves pour ou contre l'utilité d'un outil peuvent s'accumuler assez rapidement. Le seul «processus» que j'ai vu a toujours du succès, c'est que plus d'une paire d'yeux devrait voir le code. Le mécanisme par lequel ce visionnage est réalisé n'a pas d'importance.

La liberté des développeurs est une toute autre question. J'ai la chance d'avoir un travail où j'ai presque la liberté de choisir tout ce qui concerne mon environnement de développement. (Exemple: je travaille dans un magasin Red Hat, mais j’avais un budget pour acheter un ordinateur et installer Debian.) Depuis plus de 20 ans que je possède une expérience continue en développement de logiciels, je peux généralement faire de très bons choix quant aux langues et outils à utiliser. utilisation. Mais le revers de la médaille, c'est que je peux être raisonnablement productif dans toutes les langues et tous les environnements. Utiliser perl ou C ++ pourrait me ralentir d'un facteur 2 ou 3, et utiliser Lua ou Haskell m'accélérerait pour certains problèmes, mais j'y arriverai à la fin.

Mais j’ai travaillé avec d’autres développeurs qui ont une zone de confort très limitée en termes de langage et d’outils et qui choisiront avec enthousiasme un très mauvais outil pour le travail s’ils en ont la liberté. Une fois, en tant que consultant, on m'a demandé d'essayer d'aider un groupe à accélérer un compilateur qui prenait 24 heures pour compiler de petits programmes. Il s'est avéré que les personnes qui l'avaient écrit étaient des experts du système et qu'ils avaient écrit un compilateur à l'aide d'un moteur d'inférence à base de règles. Ils ont réussi à le faire fonctionner, mais c'était la mauvaise technologie pour le travail.

J'ai également constaté que le fait de contraindre un développeur à un environnement ou à un langage particuliers ne garantit pas son succès. Je me considère comme un très mauvais programmeur Perl; En gros, je traite perl comme un awk avec des stéroïdes. Je suis un idiot complet. Et pourtant, j’ai eu à faire face à du code Perl écrit par d’autres qui était bien pire que tout ce que j’aurais pu écrire juste parce qu’ils n’avaient jamais appris à penser aux problèmes ou à la façon d’organiser le code.

Je pense que je ferais mieux de cesser de parler maintenant.

Answer 9

Travailler dans des groupes plus importants a appris les valeurs des processus établis et documentés.

Tant que vous travaillez dans une petite équipe (2 à 4 personnes) où vous connaissez bien tout le monde et que vous avez tous un objectif commun, vous pouvez probablement travailler très bien sans processus défini.

Dès que 10 personnes devront coopérer, vous voudrez au moins quelques règles de base pour que tout le monde soit du même côté.

Lorsque vous réalisez un projet avec 100 personnes, vous n'aboutirez nulle part, sauf si vous avez des règles très spécifiques et un processus bien défini.

Personnellement, je préférerais que je puisse faire ce que je veux et que tout le monde travaille selon un processus strict; -)

Answer 10

Il existe différents aspects de la liberté. Lorsque vous ne pouvez pas modifier la moitié de la base de code, car il est déjà "testé" (même s’il est mal codé), je dirais que c’est un cas où vous avez besoin de liberté, mais je ne pense pas que vous en parliez.

La liberté du style des hackers, utiliser tous les outils nécessaires pour résoudre le problème, et résoudre ce problème en tant qu'objectif principal me terrifie de nos jours.

Je n'ai jamais vu de code qui n'avait pas besoin de débogage / correction à un moment donné, et le débogage / correction semble toujours prendre plus de temps que le codage initial, de sorte que le premier cycle de débogage / maintenance / amélioration facile que possible doit être votre objectif principal.

Ceci entre en conflit avec " Liberté " parce que " Liberté " Cela signifie souvent que vous êtes en mesure de choisir des mécanismes qui demanderont plus de temps aux autres personnes - et il est fort probable que d’autres personnes effectueront cette première phase de maintenance.

Answer 11

Et si vous aspiriez à la liberté, soyez créatif dans de nouvelles zones de projet au lieu d’inventer un autre processus de développement?

Answer 12

"Succès contre liberté" implique que si vous êtes libre de prendre des décisions, le programme ne sera pas un succès.

Je pense que vous devez vraiment repenser cela. D'après mon expérience, les développeurs doivent être libres de choisir la meilleure méthode d'implémentation, si celle-ci est meilleure après un examen que la méthode "testée et testée". méthodes, il sera conservé et utilisé par le reste de l’équipe. Mais ils doivent encore s'assurer que le code qu'ils écrivent réussit à accomplir les tâches pour lesquelles ils sont censés s'acquitter.

Answer 13

" Liberté " dans ce cas, cela semble juste être un mot émotionnellement positif lié à un concept déplaisant. Il pourrait tout aussi facilement être remplacé par "obstination". ou "imprudence". Même la question elle-même est formulée comme suit: "Ce que je veux faire" par rapport à "ce qui est susceptible de fonctionner".

Bien entendu, chacun est libre de suivre la voie de son choix. Mais personnellement, je ne consacrerais pas un moment de ma vie à quelque chose qui me serait indifférent et si je m'en souciais, je ferais tout ce que je pouvais pour maximiser ses chances de réussite. Je ne vois pas cela comme "restrictif". du tout.

Answer 14

La question de savoir si rester avec la sagesse conventionnelle ou "penser en dehors de la boîte" a toujours existé dans la plupart des disciplines, pas seulement en programmation. Je pense que cela doit être décidé au cas par cas.

Je suis allé à des conférences où les journaux les plus populaires semblent être des analyses approfondies des choses telles qu’elles sont. Un peu comme dans SO, où les idées populaires sont votées favorablement.

Ce serait OK s’il n’y avait pas de problèmes graves sur le terrain. Une grande partie (sinon la plupart) des logiciels sont encore bien trop lourds (IMHO) et souffrent de problèmes de performances chroniques. Les choses telles quelles sont stables, mais sont-elles assez bonnes?

Je pense que nous avons besoin de nouvelles idées, qui seront nécessairement impopulaires, non conventionnelles et risquées pendant un certain temps.

Je suis heureux que SO permette de discuter des idées non conventionnelles, non pas comme des flammes, mais comme des moyens de remettre en question le statu quo.

Answer 15

Est-ce que cela dépend aussi de ce que vous allez construire à la fin?

Ces personnes suivent les processus établis: http://www.fastcompany.com/magazine /06/writestuff.html