«Tant que ça marche» est-ce la norme? [fermé]

Voir ma question la plus récente: la programmation en tant que profession dans une course vers le bas?

Ma dernière boutique n'avait pas de processus. Agile signifiait essentiellement qu'ils n'avaient aucun plan sur la façon de développer ou de gérer leurs projets. Cela signifiait "hé, voici une tonne de travail. Allez-y en deux semaines. Nous sommes rapides et agiles."

Ils ont sorti des trucs qu'ils savaient avoir des problèmes. Ils se moquaient de la façon dont les choses étaient écrites. Il n'y a pas eu de révision de code - malgré plusieurs développeurs. Ils ont sorti un logiciel qu'ils savaient bogué.

À mon travail précédent, les gens avaient l'attitude tant que ça marche, ça va. Quand j'ai demandé une réécriture du code que j'avais écrit pendant que nous explorions essentiellement la spécification, ils l'ont refusé. Je voulais réécrire le code parce que le code était répété à plusieurs endroits, il n'y avait pas d'encapsulation et cela prenait du temps aux gens pour y apporter des modifications.

Donc, essentiellement, mon impression est la suivante: la programmation se résume à ce qui suit:

1. Lecture d'un livre sur les derniers outils / technologies
2. Regrouper le code sur la base de cela, en évitant d'écrire un code individuel car l'entreprise ne veut pas "maintenir le code personnalisé"
3. Le montrer et passer à la chose suivante, "tant que cela fonctionne".

Je me suis toujours dit que mon prochain boulot allait devenir un meilleur magasin. Ça n'arrive jamais. Si c'est ça, alors je me sens coincé. Les technologies changent toujours; si le seul développement professionnel ici est la lecture du dernier livre sur la technologie MS Press, qu'avez-vous construit en 10 ans, sinon une connaissance superficielle de diverses technologies? Je suis préoccupé par:

1. Le meilleur moyen d'avoir des normes professionnelles
2. Comment développer des connaissances et une expérience significatives dans cette situation

Vous êtes indirectement tombé sur ce que je pense être l'aspect clé pour être un bon développeur : trouver l'équilibre entre " tant qu'il fonctionne " et un code élégant et bien conçu.

Tout comme en politique, il est beaucoup plus facile de jalonner sa position à une extrémité du spectre plutôt que de prendre une position nuancée au milieu. La majorité des développeurs que je rencontre tombent dans l'une des deux catégories suivantes: codage des hacks de cow-boy et des astronautes d'architecture. J'essaie de trouver un équilibre entre les deux. Ce n'est pas aussi simple qu'il y paraît.

Pour répondre plus directement à votre question, oui, je pense que "tant que ça marche" est souvent la norme. Mais regardez les choses autrement: vous êtes en excellente position pour éduquer vos collègues et essayer d'introduire de meilleures pratiques. Mais n'allez pas à l'extrême et rappelez-vous pourquoi nous faisons tous cela: pour résoudre les problèmes de nos clients.

>> Dans mon travail précédent, les gens avaient l'attitude tant que ça marche, ça va.

Je suis peut-être une minorité ici, mais j'ai la même attitude et je crois fermement que pour réécrire quelque chose, il devrait y avoir des preuves claires de la raison pour laquelle nous en avons besoin. Et je ne veux pas dire quelque chose comme "uf, je n'aime pas comment il a été codé" - chaque développeur a ses préférences concernant le code. Il devrait y avoir quelques problèmes avec la partie que nous voulons réécrire:

• Problèmes de performances
• Il y avait plus de bugs trouvés que dans toutes les autres parties du système
• Les développeurs passent plus de temps lorsqu'ils travaillent sur cette partie
• etc.

Agile n'est pas responsable de tout humain décidant de publier un logiciel buggy; les humains le sont.

Cela dit, vous accordez beaucoup d'importance à la qualité, et c'est bien. Je suis sûr que vous êtes un perfectionnisme et que vous êtes préoccupé par votre propre valeur si vous ne rattrapez pas les dernières technologies.

Le problème est que le perfectionnisme conduit à la procrastination et la procrastination conduit à la médiocrité .

C'est pourquoi les entreprises accorderont la priorité à des choses comme le temps de mise sur le marché et utiliseront l' agilité pour fournir de la valeur rapidement et à un rythme prévisible.

Comme vous n'avez pas décrit la stratégie commerciale de votre entreprise, je pense que vous devriez commencer par poser des questions à ce sujet à vos managers.

En étant aligné sur leurs objectifs et leurs plans (ils vous ont embauché pour les aider à les atteindre), vous serez mieux placé pour comprendre comment vous pourriez y contribuer au lieu de vous concentrer sur vos propres objectifs et sur vos objectifs personnels.

Je suis sûr qu'en essayant à understandleur valeur, vous pourrez partager la vôtre, et ce sera le début d'une collaboration fructueuse.

Et si vous découvrez qu'ils ne savent pas ce qu'ils font, votre seule option sera d' arrêter .

Tout dépend de ce que vous construisez. Si vous construisez un microsite qui ne sera en ligne que pendant un mois et que vous avez neuf jours pour le construire: alors oui, tant qu'il fonctionne, cela suffira.

Si vous écrivez les algorithmes fly-by-wire pour le système FA-18, alors il vaut mieux être construit aussi parfaitement que possible.

Donc, comme c'est le cas avec la plupart des réponses technologiques ... cela dépend.

Cela dépend de l'entreprise. Cependant, de nombreuses entreprises font face à une concurrence sérieuse et à des contraintes de temps. C'est une raison typique. Une autre serait une charge de travail importante, potentiellement sans personnel suffisant. (Il existe de très bonnes raisons d'être en sous-effectif, ce qui n'est pas nécessairement la faute de l'entreprise.) Cela dit, certaines organisations ne pouvaient pas se sortir d'un sac en papier humide.

Je pense que la règle des 80/20 s'applique ici. Fondamentalement, vous devez supporter les 80% de merde et progresser dans les 20%. Cependant, sachez que même ils devront faire des compromis. En affaires, peu importe que vous ayez tout à fait raison. Il importe que vous l'ayez maintenant.

si le seul développement professionnel ici est la lecture du dernier livre sur la technologie MS Press, qu'avez-vous construit en 10 ans, sinon une connaissance superficielle de diverses technologies?

Ce serait plutôt nul mais il y a peut-être eu des échecs spectaculaires à noter au cours de cette décennie. J'ai vu de nombreux endroits où je me souviens de choses plutôt spécifiques que j'aimais travailler ou que je n'aimais pas et je remettrais donc en question le fait d'avoir à nouveau cela dans mon nouveau lieu de travail. Parfois, il peut y avoir une nouvelle pratique à essayer, comme si une entreprise essaye d'implémenter Scrum ou d'adopter une approche de développement piloté par les tests, cela peut être des opportunités mais pas nécessairement considérées comme du développement professionnel car ce n'est pas dans une salle de classe formelle.

Je connais divers endroits où le "tant qu'il fonctionne" est commun avec diverses stratégies de codage de cowboy. Dans quelques start-ups, j'ai vu ce genre de mentalité qui peut avoir du sens si l'entreprise est si jeune qu'elle essaie toujours de débusquer l'idée de ce qu'elle essaie vraiment de faire. Dans d'autres entreprises où j'ai travaillé, il y a eu plus de processus et une maturité qui peut être assez bonne mais pas nécessairement facile à trouver, je le crains. Certains endroits ont eu des processus que j'ai pu voir et suivre: «J'aime ça. Je m'en souviendrai pour des situations de travail ultérieures», et d'autres où j'irais: «Je n'aime vraiment pas ça. Je noterai pour essayer d'éviter cela à l'avenir. "

J'ai travaillé dans un magasin comme celui-ci pendant un certain temps juste au moment où il les rattrapait. Il y avait des applications vieilles de deux ou trois ans avec des bogues connus qu'elles ne pouvaient littéralement pas résoudre. Pensez à une boucle longue de 4000 lignes avec un calcul en cours pour les largeurs et hauteurs de mise en page. La correction d'un morceau de code pour réparer un problème dans une instance entraînerait vingt problèmes ailleurs car les développeurs antérieurs avaient des problèmes similaires avec l'aide de bandes en ajustant arbitrairement les résultats des calculs avec des nombres magiques. Le code ne pouvait pas être décrit comme autre chose que toxique.

On m'a finalement remis un nouveau projet dont mon patron m'a dit qu'il pouvait utiliser ce code existant pour gérer les mises en page. D'une certaine manière, je l'ai convaincu de me laisser "le modifier" alors il m'a donné un peu de temps supplémentaire. J'ai utilisé le temps pour écrire une bibliothèque bien conçue pour aider à la mise en page. Les bugs de ce nouveau projet m'ont littéralement pris 10 secondes à résoudre. J'ai pu identifier les problèmes avant même de regarder le code pour voir ce qui n'allait pas.

Je pensais que cela entraînerait un tournant pour mon manager, mais tout ce que j'ai obtenu était une tape dans le dos et il m'a essentiellement dit que "votre chemin fonctionne aussi, je suppose."

Depuis, j'ai commencé à travailler pour un autre magasin et les choses vont mieux ici. Le fait est que vous ne pouvez pas changer d'avis. Allez travailler ailleurs.

J'ai toujours l'espoir que, dans l'économie, il y a une sorte de processus évolutif qui, tôt ou tard, met ces entreprises à la faillite. Mais le rythme élevé du progrès technologique produit peut-être trop de niches nouvelles, de sorte que même les concurrents faibles peuvent toujours trouver suffisamment de «nourriture».

Si vous souhaitez augmenter vos chances de travailler dans un bon endroit, recherchez une entreprise qui a un produit qu'ils vendent à de nombreux clients au lieu d'écrire quelque chose de nouveau toutes les quelques semaines. Il devrait y avoir plus d'intérêt à avoir une bonne base de code et à pouvoir ajouter de nouvelles fonctionnalités sans casser le code existant tout le temps.

Ça me rappelle mon camarade de classe. Il suivait un cours de conception VLSI, et pour ses premiers devoirs, il a proposé un composant qui était de l'ordre de micromètres de large et d'un mile de long. Les simulations se sont parfaitement déroulées.

Sa réponse à ses détracteurs a été: "Tout ce que je sais, c'est que ma merde fonctionne.".

Une assez bonne norme est le principe de Pareto

J'ai l'expérience d'un projet avec la règle 80-20 et cela a très bien fonctionné. Je pense que les réponses à cette question "Où tracez-vous la ligne de votre perfectionnisme" peuvent également être utiles.

Le terme «principe de Pareto» peut également désigner l'efficacité de Pareto. Le principe de Pareto (également connu sous le nom de règle 80-20, de la loi de quelques-uns et du principe de la rareté des facteurs) stipule que, pour de nombreux événements, environ 80% des effets proviennent de 20% des causes. Le penseur en gestion d'entreprise Joseph M. Juran a suggéré le principe et l'a nommé d'après l'économiste italien Vilfredo Pareto, qui a observé en 1906 que 80% des terres en Italie appartenaient à 20% de la population; il a développé le principe en observant que 20% des gousses de pois dans son jardin contenaient 80% des pois. C'est une règle d'or courante dans les affaires; par exemple, "80% de vos ventes proviennent de 20% de vos clients". Mathématiquement, lorsque quelque chose est partagé entre un ensemble suffisamment grand de participants, il doit y avoir un nombre k compris entre 50 et 100 tel que "k% est pris par (100 - k)% des participants". Le nombre k peut varier de 50 (dans le cas d'une répartition égale, c'est-à-dire que 100% de la population ont des parts égales) à près de 100 (lorsqu'un petit nombre de participants représente la quasi-totalité de la ressource).Le nombre de 80% n'a rien de spécial mathématiquement, mais de nombreux systèmes réels ont k quelque part autour de cette région de déséquilibre intermédiaire dans la distribution. Le principe de Pareto n'est que tangentiellement lié à l'efficacité de Pareto, qui a également été introduite par le même économiste. Pareto a développé les deux concepts dans le contexte de la répartition des revenus et des richesses au sein de la population.

Lien vers la source

Quand j'ai demandé une réécriture du code que j'avais écrit pendant que nous explorions essentiellement la spécification, ils l'ont refusé. Je voulais réécrire le code parce que le code était répété à plusieurs endroits, il n'y avait pas d'encapsulation et cela prenait du temps aux gens pour y apporter des modifications.

Aucune infraction, mais en tant que manager, j'ai lu cette déclaration quelque part dans le sens de:

"Quand j'ai demandé à être payé deux fois pour réécrire un code que j'avais déjà écrit, mon entreprise ne voulait pas payer. Je voulais l'argent supplémentaire pour nettoyer le gâchis que j'ai fait quand je l'ai écrit la première fois, et mon mes collègues étaient fâchés contre moi d'avoir rendu leur vie difficile. "

Si c'est votre propre code dont vous vous plaignez - vous n'avez pas grand-chose sur quoi vous tenir.

MISE À JOUR

Je comprends que ce POV est impopulaire. Mais, je ne pense pas que ce soit du tout incongru avec les responsabilités et les attitudes d'un développeur professionnel.

Si vous écrivez du code propre pour commencer (et il y a une multitude de raisons de le faire - peu importe si vous pensez que votre code sera utilisé en production ou non), alors vous aurez ce problème beaucoup moins régulièrement.

Si vous incluez du code propre et du temps de refactorisation dans vos estimations, vous aurez également le calendrier pour garder la base de code en ordre. Si, en raison des contraintes de calendrier, vous n'obtenez pas le temps nécessaire - vos estimations futures devraient augmenter en raison de la gestion de la dette technique contractée.

À un moment donné, vos estimations futures (ou les incertitudes entourant vos estimations) vous donneront un moyen de plaider pour une réécriture (lorsque votre gestionnaire vous supplie d'accélérer le processus). Si ce n'est pas le cas, acceptez que l'entreprise a accepté votre estimation et préfère payer les frais courants que pour un remplacement. C'est purement une décision commerciale - pas une décision technique.

N'oubliez pas, le temps de négocier les horaires est avant d'avoir écrit le code - pas après. Une fois le code écrit (et «fonctionne»), les clients, les gestionnaires et les cadres supérieurs ne veulent pas voir une autre facture de «maintenance» qui approche ou dépasse le coût d'origine. Si vous y pensez autant que vous le pensez, n'hésitez pas à le réécrire à votre rythme - c'est ce que vous demandez à l'entreprise de faire.

Du point de vue de votre manager, vous donner un calendrier de réécriture met son cul en jeu. Lorsque vous ne parvenez pas à livrer ou à augmenter la productivité autant que vous le dites, c'est lui qui tient le sac. Comparé à l'inconvénient relativement mineur de vous entendre vous plaindre, devinez lequel il va préférer.

Si c'est le genre de travail que vous pouvez obtenir, concentrez-vous simplement sur l'écriture d'un meilleur code à chaque fois, plutôt que de revenir en arrière et de réécrire l'ancien code. Il existe toujours une gamme de qualité dans laquelle vous pouvez vous déplacer dans le domaine du collage de packages tiers.

Si vous avez le temps et que vous souhaitez améliorer le code d'un composant existant que vous maintenez, ne pouvez-vous pas le faire sans demander la permission, tant que ce que vous faites fonctionne? Factorisez le temps dans vos estimations pour le prochain projet qui utilise le composant.

Pour la programmation de niveau inférieur, si vous ne pouvez pas obtenir de satisfaction d'apprentissage de votre travail, alors il est peut-être temps de regarder un projet open source?

q303, j'ai trouvé votre question intéressante et j'ai pensé que vous pourriez trouver cette question de programmeurs digne d'être lue, sur la façon de convaincre les gestionnaires de laisser les développeurs régler la dette technique.

Je pense qu'en général, oui, c'est la norme. Comprenez que les logiciels qui fonctionnent mais qui ne sont pas optimaux sont bien meilleurs que les logiciels qui ne fonctionnent pas. Il y a aussi l'argument selon lequel la définition du «travail» pourrait varier en fonction de la perception et des préjugés de chaque individu. Lorsque vous implémentez un nouveau système, il y a toujours quelqu'un qui dira qu'il pensait que l'ancien système était meilleur. Et lorsque vous parlez à un développeur, il ou elle est susceptible d'être réticent à admettre avoir travaillé sur un logiciel de merde.