Comment conciliez-vous entre «le faire correctement» et «le faire le plus tôt possible» dans votre travail quotidien?
Je me retrouve à réfléchir à cette question de temps en temps, encore et encore. Je veux faire les choses de la bonne façon: écrire du code propre, compréhensible et correct, facile à maintenir. Cependant, ce que je finis par faire, c'est d'écrire patch sur patch; juste parce qu'il n'y a pas de temps, les clients attendent, un bug devrait être corrigé du jour au lendemain, l'entreprise perd de l'argent sur ce problème, un responsable fait pression, etc., etc.
Je sais parfaitement qu'à long terme, je perds plus de temps sur ces patchs, mais comme cette période s'étend sur des mois de travail, personne ne s'en soucie. Aussi, comme disait un de mes managers: "nous ne savons pas s'il y aura un long terme si nous ne le réparons pas maintenant".
Je suis sûr que je ne suis pas le seul pris au piège dans ces cycles de choix réels/idéaux sans fin. Alors comment, mes collègues programmeurs, gérez-vous cela?
MISE À JOUR: Merci à tous pour cette discussion intéressante. Il est triste que tant de gens doivent choisir quotidiennement entre une quantité et une qualité de leur code. Pourtant, étonnamment nombreux, les gens pensent qu'il est possible de gagner cette bataille, alors merci à tous pour ces encouragements.
En fait, c'est une question très difficile car il n'y a pas de réponse absolument juste. Dans notre organisation, nous avons mis en place de meilleurs processus pour produire un meilleur code. Nous avons mis à jour nos normes de codage pour refléter la façon dont nous, en tant que groupe, écrivons du code, et nous avons mis en place une boucle de test/refactor/design/code très solide. Nous livrons continuellement ou du moins essayons de le faire. À tout le moins, nous avons quelque chose à montrer aux parties prenantes toutes les deux semaines. Nous pensons que nous sommes des artisans du logiciel et le moral est élevé. Mais, malgré tous ces freins et contrepoids, nous souffrons du même problème que vous.
En fin de compte, nous livrons un produit à un client payant. Ce client a des besoins et des attentes, réalistes ou non. Souvent, l'équipe de vente nous pose des problèmes juste pour obtenir une commission. Parfois, le client a des attentes irréalistes ou un changement de demande, même si nous avons un contrat en place. Les échéances arrivent. La prise de force et les jours perdus pendant un sprint peuvent survenir. Toutes sortes de petites choses peuvent culminer dans une situation où nous sommes contraints à l'énigme du "bien faire" ou du "faire le plus tôt possible". Presque toujours, nous sommes obligés de "le faire dès que possible".
En tant qu'artisans du logiciel, développeurs, programmeurs, personnes qui codent pour un travail - c'est notre tendance naturelle à "le faire correctement". "Do it ASAP" est ce qui se passe lorsque nous travaillons pour survivre, comme la plupart d'entre nous. L'équilibre est difficile.
Je commence toujours par approcher la direction (je suis directeur du développement logiciel et développeur actif dans ce groupe) pour défendre le planning, l'équipe et le travail en cours. Habituellement, à ce moment-là, on me dit que le client doit l'avoir maintenant et que cela doit fonctionner. Quand je sais qu'il n'y a pas de place pour la négociation ou pour donner, je retourne travailler avec l'équipe pour voir quels coins peuvent être coupés. Je ne sacrifierai pas la qualité de la fonctionnalité qui motive le client à l'obtenir dès que possible, mais quelque chose ira et sera poussé dans un autre sprint. C'est presque toujours OK.
Lorsque vous ne parvenez pas à livrer car il y a tellement de bogues, la qualité du code est mauvaise et empire, et les délais deviennent plus courts, alors vous êtes dans une situation différente de celle que je décris. Dans ce cas, une mauvaise gestion actuelle ou passée, de mauvaises pratiques de développement qui ont conduit à une mauvaise qualité du code ou d'autres facteurs peuvent vous entraîner dans une marche de la mort.
Mon opinion ici est de faire de votre mieux pour défendre le bon code et les meilleures pratiques pour commencer à sortir votre entreprise des tranchées. S'il n'y a pas un seul collègue prêt à écouter ou à se battre pour le groupe contre la direction, alors il pourrait être temps de commencer à chercher un nouvel emploi.
En fin de compte, la vraie vie l'emporte sur tout. Si vous travaillez pour une entreprise qui a besoin de vendre ce que vous développez, vous rencontrerez ce compromis quotidiennement. Ce n'est qu'en m'efforçant de parvenir tôt à de bons principes de développement que j'ai réussi à garder une longueur d'avance sur la courbe de qualité du code.
Le push and pull entre développeurs et vendeurs me rappelle une blague. "Quelle est la différence entre un vendeur de voitures d'occasion et un vendeur de logiciels? Au moins, le vendeur de voitures d'occasion sait qu'il ment." Gardez le menton levé et essayez de "faire la bonne chose" au fur et à mesure.
Une chose que j'ai réalisée dans ma carrière, c'est qu'il y a toujours le temps de bien faire les choses. Ouais, votre manager peut pousser. Le client pourrait être énervé. Mais ils ne savent pas combien de temps les choses prennent. Si vous (votre équipe de développement) ne le faites pas, cela ne se fait pas; vous détenez tous les effets de levier.
Parce que vous savez ce qui va vraiment amener votre manager à vous pousser ou à vexer votre client? mauvaise qualité.
Cela se résume à ce que j'ai commencé à penser comme "le conflit éternel" (entre les affaires et l'ingénierie). Je n'ai pas la solution car c'est un problème qui ne disparaît jamais mais vous pouvez faire des trucs pour aider à atténuer.
- Communiquer la valeur
Ce que les gens ne réalisent souvent pas, c'est qu'en tant qu'ingénieurs, nous supposons simplement que le problème de la "réussite commerciale" est toujours acquis. Nous voulons que notre code soit agréable et soigné et maintenable afin que nous puissions ajouter de nouvelles fonctionnalités et modifier celles existantes rapidement et avec un minimum de clients faisant de l'AQ pour nous en découvrant des cas marginaux bizarres qui auraient été contrecarrés par un meilleur code. Garder les clients et maintenir un avantage concurrentiel avec des fonctionnalités et une finesse que personne d'autre ne peut produire assez rapidement sont à la fois des gains commerciaux auxquels un bon code contribue directement et qui expliquent en grande partie la raison pour laquelle nous voulons un meilleur code en premier lieu.
Alors expliquez-le. "Nous voulons faire X dans notre base de code parce que si nous ne le faisons pas, cela aura un impact négatif sur les affaires en raison de Y" ou "... parce qu'il améliorera notre capacité à rester compétitif en améliorant notre capacité à transformer de nouvelles améliorations et fonctionnalités plus rapidement . "
Et faites de votre mieux pour essayer d'obtenir des preuves tangibles que les améliorations fonctionnent. Si l'amélioration d'un sous-ensemble d'une application a entraîné une fonctionnalité/amélioration plus rapide, vérifiez quel outil de backlog vous pourriez utiliser pour en prouver la preuve et le signaler lors des réunions appropriées.
- Obtenez l'équipe sur la même page
Les Egos sont souvent un problème. Une chose dont les équipes d'ingénieurs ont grandement besoin est d'établir la valeur d'avoir une sorte d'approche cohérente et convenue pour résoudre certains types de problèmes par rapport à tout le monde qui fait sa propre tasse de Kool Aid d'hôte parce qu'ils savent mieux. Il est normal de croire que la préférence de l'autre gars est pire que la vôtre, mais valorisez la cohérence plutôt que d'être plus juste si son approche est réalisable et c'est un argument que vous ne pouvez pas gagner. Le compromis dans un souci de cohérence est la clé. Lorsque les choses sont cohérentes, il est plus difficile de les mal faire, car la méthode établie cohérente sera généralement aussi la plus rapide.
- Choisissez les bons outils
Il existe deux écoles de frameworks/jeux d'outils/bibliothèques/quoi que ce soit. "Définissez-en 99% pour moi, donc je dois savoir/faire très peu" vs "rester à l'écart quand je ne veux pas de vous, mais aidez-moi à bricoler très rapidement et de manière cohérente avec les choses que je veux réellement à utiliser sur le principe de la carotte plutôt que du bâton. " Privilégiez le second. La flexibilité et le contrôle granulaire ne devraient jamais être sacrifiés sur l'autel de la rotation rapide parce que biz, "nous ne pouvons pas le faire parce que nos propres outils ne nous le permettent pas" n'est jamais une réponse acceptable et la question se posera toujours pour les non ingénierie de produits triviale/jetable. D'après mon expérience, les outils inflexibles sont presque toujours ouverts ou travaillés de manière inélégante et font un gros gâchis géant impossible à maintenir. Plus souvent qu'autrement, les solutions flexibles/plus faciles à modifier sont tout aussi ou presque aussi rapides à court terme, peu importe. Rapide, flexible et maintenable sont possibles avec les bons outils.
- FFS, si les ingénieurs ne décident pas, obtenez au moins la contribution de l'ingénieur pour choisir les outils
J'ai l'impression qu'il s'agit d'une question de perspective de développeur, mais j'ai été dans beaucoup trop de situations où les décisions technologiques ont été prises sans aucune contribution d'ingénieur. Qu'est-ce que c'est que ça? Oui, quelqu'un doit finalement faire le dernier appel, mais obtenez des opinions qualifiées si vous êtes un gestionnaire non technique, pas ce que certains vendeurs ou sites de démonstration disent de ses propres produits. Tout ce qui promet de vous faire économiser de l'argent parce que les gens n'ont pas besoin d'être aussi intelligents ou parce qu'il protège les développeurs d'eux-mêmes est un mensonge sale et sale. Embauchez des talents en qui vous pouvez avoir confiance. Expliquez-leur ce que vous voulez d'une pile ou d'une autre solution technologique et prenez leur avis au sérieux avant de décider sur quel mouvement technologique se lancer.
- Concentrez-vous sur la conception plutôt que sur la mise en œuvre
Les outils sont destinés à la mise en œuvre et en tant que tels, ils peuvent vous aider, mais la première priorité doit être l'architecture, quel que soit le jeu de jouets dont vous disposez pour construire cette architecture. À la fin de la journée KISS et DRY et toutes les excellentes philosophies qui en découlent plus que si c'est en .NET ou Java ou peut-être quelque chose qui est à la fois gratuit ET ne craint pas.
- Enregistrez vos préoccupations
Lorsque le côté biz insiste pour que vous le fassiez mal, enregistrez cet e-mail, en particulier la partie où vous avez dit pourquoi cela vous coûterait. Lorsque toutes vos prévisions se réalisent et que de graves problèmes néfastes surviennent, c'est alors que vous avez un tas d'arguments pour prendre les préoccupations des ingénieurs plus au sérieux. Mais chronométrez soigneusement les choses. Au milieu de l'enfer flamboyant, c'est un mauvais moment pour un "je vous l'ai dit" sur le code d'incendie suivant. Éteignez le feu et apportez votre liste des préoccupations précédemment ignorées à une réunion/conversation rétrospective, et essayez de garder l'accent sur les préoccupations techniques exprimées et ignorées et sur le raisonnement que vous avez compris pourquoi elles étaient ignorées, pas sur les noms des personnes réelles prendre la décision d'ignorer. Tu es ingénieur. Restez sur les problèmes, pas sur les gens. "Nous avons exprimé notre inquiétude à propos de X parce que nous craignions que cela n'entraîne des problèmes avec Y. On nous a dit de Z et de différer le traitement."
Il n'y a qu'une seule solution. Réservez environ 10 à 20% du temps de projet/travail pour le refactoring. S'il est difficile de convaincre la direction que c'est une tâche justifiable, donnez-lui le seul véritable argument: sans refactorisation, le coût de la maintenance du code augmentera de façon exponentielle au fil du temps. C'est bien d'avoir quelques métriques/articles/résultats de recherche pour sauvegarder cette thèse lors de la rencontre avec le manager :)
Edit: il y a quelques bonnes ressources sur "refactoring vs hausse des coûts de maintenance" mentionnées dans ce livre blanc: http://www.omnext.net/downloads/Whitepaper_Omnext.pdf
Chaque fois que vous avez le temps de faire quelque chose de bien, utilisez-le - écrivez le meilleur code possible et améliorez-le régulièrement. Ne rendez pas votre travail plus difficile en étant bâclé et en introduisant une dette technique lorsque cela n'est pas nécessaire.
Les appels d'urgence pour corriger un bug grave ne sont pas des choses que vous pouvez contrôler par vous-même, quand ils se produisent, vous devez réagir dès que possible, c'est la vie. Bien sûr, si vous avez l'impression que tout votre travail consiste en appels d'urgence et que vous n'avez jamais assez de temps pour bien faire les choses, alors vous êtes sur la voie de l'épuisement professionnel et devez parler à votre patron.
Si cela ne vous aide pas, il reste la "stratégie de Scotty" pour avoir suffisamment de temps pour bien faire les choses: multipliez toutes vos estimations par un facteur de 4:
http://blogs.popart.com/2007/07/what-scotty-from-star-trek-can-teach-us-about-managing-expectations/
Je considère que mon travail consiste à fournir le meilleur logiciel de qualité possible dans les délais impartis pour le projet. Si je crains que le niveau de qualité soit faible, j'engagerai le maître d'ouvrage. Je décris mes préoccupations et discute des risques potentiels du déploiement du logiciel dans cet état. Une des trois choses va se produire à ce stade:
Le propriétaire du projet ne voudra pas accepter les risques et repoussera le calendrier pour nous permettre de consacrer plus de temps à la qualité des logiciels.
Le maître d'ouvrage ne voudra pas accepter les risques mais ne pourra pas reculer le planning. Si cela se produit, nous devons négocier les caractéristiques/fonctionnalités à supprimer de la portée du projet afin de consacrer plus de temps à la qualité du logiciel pour les principales parties de l'application.
Le maître d'ouvrage acceptera les risques et le logiciel de mauvaise qualité sortira dans les délais. Parfois, le risque commercial de ne rien déployer (ou de le déployer tardivement) est beaucoup plus élevé que le risque commercial de déployer des logiciels de faible qualité, et seul le propriétaire du projet peut prendre cette décision.
Écrire un logiciel, c'est un peu comme peindre un portrait. Il est impossible de dire qu'un portrait est fait "à droite" ou "parfait". Parfait est l'ennemi du fait. Vous pourriez littéralement passer 1 mois à travailler sur une seule méthode et elle ne serait toujours pas considérée comme "parfaite" par certains. Mon travail consiste à peindre un portrait dont le client est satisfait.
L'équilibre optimal peut être de consacrer autant de temps supplémentaire à le faire correctement que vous perdriez à corriger les bugs que vous éliminez en le faisant correctement. Évitez de plaquer l'or de la solution. Dans la plupart des cas, la solution Volkswagen bien faite est aussi bonne que la solution Cadillac. Vous pouvez généralement mettre à niveau plus tard lorsqu'il est prouvé que vous avez besoin de la Cadillac.
La correction d'un code qui n'a pas suivi les meilleures pratiques prend souvent beaucoup plus de temps. Essayer de trouver d'où vient le null lorsque l'appel ressemble à a.b.c.d.e (), peut prendre beaucoup de temps.
L'application de DRY et la réutilisation du code existant sont généralement beaucoup plus rapides que le codage et le test d'une autre solution. Il facilite également l'application des modifications lorsqu'elles se produisent. Il vous suffit de modifier et de tester un seul ensemble de code, pas deux, trois ou vingt.
Visez un code de base solide. Beaucoup de temps peut être perdu en essayant de le rendre parfait. Il existe des bonnes pratiques qui conduisent à un code rapide, mais pas nécessairement le plus rapide possible. Au-delà de cela, essayer d'anticiper les goulots d'étranglement et d'optimiser le code lors de sa construction peut être une perte de temps. Pire encore, l'optimisation peut ralentir le code.
Dans la mesure du possible, fournissez la solution de travail minimale. J'ai vu des semaines des solutions de placage d'or gaspillées. Soyez extrêmement prudent sur la portée.
J'ai passé un peu de temps à travailler sur un projet qui aurait dû prendre six mois. Quand je l'ai rejoint, il était en cours depuis un an et demi. Le chef de projet avait posé une question au chef de projet au départ: "Voulez-vous que je le fasse correctement ou que je sois réactif?" En une semaine, une fonctionnalité a été mise en œuvre lundi, mercredi et vendredi; Mardi et jeudi, la fonctionnalité a été supprimée.
EDIT: Lorsque le code est fait à un niveau satisfaisant, laissez-le. N'y retournez pas pour le réparer si vous trouvez une meilleure façon de le faire. Si vous devez vous faire une note. Si des changements sont nécessaires, passez en revue votre idée et mettez-la en œuvre, si elle a toujours du sens.
S'il existe des endroits où vous souhaitez implémenter des extensions pour les fonctionnalités à venir, n'implémentez pas les extensions. Vous pouvez laisser un commentaire de marqueur pour vous rappeler où apporter les modifications.
Cela ne fonctionnera pas dans tous les cas, mais j'ai eu de la chance en utilisant cette stratégie si le problème est un problème de production cassé qui doit être résolu de toute urgence. Estimez le temps de faire une solution rapide pour lancer la production et le temps de faire la solution de qualité pour l'avenir. Présentez les estimations à votre patron/client et faites approuver le temps pour les deux. Ensuite, vous effectuez la solution rapide pour obtenir le démarrage de la production et une solution à long terme immédiatement après lorsque la pression de temps urgente est désactivée. Je trouve que si je le présente car j'ai besoin de cette fois pour faire le travail correctement, mais je peux mettre en place un correctif temporaire jusqu'à ce que je puisse le faire, que mes clients semblent aimer cette approche. Il se remet à fonctionner et répond aux besoins à long terme.
Faites-le fonctionner puis rendez-le parfait
Je vais peut-être m'attarder sur ce point - mais si le temps presse, alors votre priorité devrait être de le faire fonctionner, aussi simple que cela. Donnez votre avis sur les lacunes de votre code et notez ce que vous avez fait dans n'importe quel logiciel de gestion de projet/temps que vous utilisez.
J'espère que cela vous donnera plus de temps pour revenir sur ces problèmes et les rendre parfaits.
Évidemment, il n'y a pas de réponse correcte absolue à cela, mais c'est une réponse à laquelle j'essaie de m'en tenir. Vous ne le trouverez peut-être pas adapté à votre style de travail actuel. Ce qui m'amène à l'alternative ...
Trouvez simplement une méthode qui vous convient; puis respectez-le. Chacun a sa propre façon de gérer les projets et il n'y a pas d'approche unique. Trouvez une approche et faites-en la vôtre.
"Bien faire les choses" signifie faire les bons compromis pour une situation particulière. Certains d'entre eux sont:
- Temps et coût de développement
- Facilité de lecture, de débogage et de mise à jour du code ultérieurement (tout, des noms de variables à l'architecture)
- Rigueur de la solution (cas Edge)
- Rapidité d'exécution
De toute évidence, si un morceau de code est utilisé une fois et jeté, # 2 peut être sacrifié pour n'importe lequel des autres. (Mais méfiez-vous: vous pouvez pensez vous allez le jeter, puis vous devrez continuer à l'utiliser et à le maintenir, à quel point il sera plus difficile de convaincre les gens de vous donner le temps de vous améliorer) quelque chose qui "fonctionne".)
Si vous et/ou votre équipe allez continuer à utiliser et à mettre à jour du code, prendre des raccourcis maintenant signifie simplement vous ralentir plus tard.
Si vous fournissez actuellement du code bogué (faible sur # 4) et prenez beaucoup de temps pour le faire (faible sur # 1), et c'est parce que vous essayez de mettre à jour un code qui était faible sur # 2, eh bien, vous avez a obtenu un argument solide et pragmatique pour changer vos pratiques.
Si c'est un bug, faites-le dès que possible, s'il s'agit d'une nouvelle fonctionnalité, prenez votre temps.
Et si vous travaillez pour une entreprise qui ne respecte pas le travail de développeur, vous n'avez peut-être pas d'autre choix que de le faire rapidement et de sacrifier la qualité.
J'ai travaillé pour un certain nombre d'entreprises qui iraient de projet en projet et feraient tout rapidement. En fin de compte, ils ont eu peu de succès dans chaque projet car la mise en œuvre (pas seulement la programmation) a été précipitée.
Les meilleures entreprises du monde comprennent qu'un bon logiciel demande du temps et de l'artisanat.
Voici un bon plan:
- Faites en sorte que votre plan do-it-right prenne exactement le même temps que do-it-asap.
- Optimisez votre temps pour le faire jusqu'à ce que votre environnement soit satisfait; garder la qualité
- ???
- Succès
En cas d'urgence, créez la solution de correction. Créez un nouveau bogue dans le suivi des bogues en le mentionnant. Faites les choses correctement, chaque fois que vous en avez le temps.
Je pense que je fais ce que font tous ceux qui sont coincés dans cette industrie. Je le fais aussi vite que possible et si je dois omettre certaines des bonnes choses qui pourraient aider à prévenir des problèmes à l'avenir ou à faciliter la résolution de problèmes à l'avenir, je le fais. Ce n'est pas une situation optimale, mais lorsque vous êtes coincé avec des délais basés sur des estimations basées sur des estimations, basées sur un grand nombre de variables inconnues, c'est à peu près le mieux que vous puissiez faire.
Le logiciel est quelque chose de bizarre et le processus de développement logiciel est plus étrange.
Contrairement à la plupart des choses dans la vraie vie, mais comme la plupart des choses à faire avec les ordinateurs
Plus rapide est plus fiable
Cela va à l'encontre de toutes les intuitions que votre vie vous a enseignées jusqu'à présent, les voitures hautement réglées tombent en panne plus souvent que les voitures standard, les maisons construites rapidement s'effondrent plus rapidement, les devoirs faits à l'arrière du bus scolaire n'obtiennent pas de notes élevées.
Mais les procédures méthodiques lentes ne produisent pas de meilleurs logiciels. Les gars qui passent des semaines à produire des documents d'exigences et des jours sur des diagrammes de classes avant d'écrire du code ne produisent pas de meilleurs logiciels. Le gars qui obtient l'exigence de base, clarifie quelques problèmes, gribouille un diagramme de classe sur le tableau blanc et obtient le codage de son équipe produira presque toujours un logiciel plus fiable et meilleur, et ce, en quelques jours plutôt qu'en plusieurs mois.
Je fais la plupart des choses de façon routinière, la première façon qui me vient à l'esprit. C'est rapide, et j'aime à penser que je suis un programmeur décent et que je fais la plupart des choses raisonnablement bien du premier coup.
De temps en temps (je voudrais dire deux fois par jour, mais deux fois par semaine est plus réaliste), surtout quand je trouve quelque chose d'extrêmement ennuyeux à faire de façon routinière, je pense "ce qui serait un IMPRESSIONNANT moyen de le faire? " et je passe le temps supplémentaire à trouver ou à inventer une meilleure façon de le faire.
Si je continue à le faire assez souvent, mon codage de routine continuera de s'améliorer, je pense.