Un développeur doit-il s'opposer aux fonctionnalités inutiles ou nuisibles?

Quelle est la bonne attitude des développeurs lorsqu'ils discutent de nouvelles fonctionnalités, et notamment des fonctionnalités non critiques / discutables?

Imaginons que vous développiez une sorte de langage de type Java, et le patron dit: "Nous avons besoin de pointeurs pour que les développeurs puissent jouer directement avec la mémoire des objets!"

Le développeur doit-il abattre l'idée parce qu'elle ajoute une complexité et des vulnérabilités de sécurité inimaginables, ou doit-il faire ce qui est demandé?

Ce n'est peut-être pas un bon exemple, mais qu'en est-il des choses qui sont plus dans une zone grise, comme l'ajout de boutons qui interrompent le flux de travail ou vont à l'encontre de la structure interne du programme, etc.?

Quelle est la distribution optimale "peut faire" contre "ne peut pas faire" pour un programmeur ordinaire?

EDIT: La question ne concerne pas un mauvais patron: D

J'étais plus intéressé par la façon dont les gens abordent les nouveaux problèmes qui ajoutent une quantité notable de problèmes tout en étant peut-être légèrement utiles.

L'attitude générale devrait-elle être:

1. oui on va le faire, foutre la complexité
2. peut être
3. non, le remaniement général et les implications ne justifient pas le changement

Quelle devrait être la réaction d'un bon développeur?

La meilleure chose est d'avoir une réunion et de présenter les avantages et les inconvénients en tant que groupe et, sur cette base, de discuter de la meilleure solution. Si vous avez une équipe, demandez-leur de se mettre d'accord sur la solution. Une fois qu'une équipe est d'accord sur quelque chose, les gestionnaires et les «patrons» ont tendance à choisir la solution.

Si votre patron n'est toujours pas d'accord, alors vous avez fait tout ce que vous pouvez faire: vous avez réuni votre équipe et vos gestionnaires et couvert les avantages et les inconvénients et malgré cela, votre patron a choisi une solution potentiellement inférieure.

La clé de tout cela est de discuter des avantages et des inconvénients en tant que groupe. Ce faisant, vous discutez de la meilleure solution avec votre équipe et, en même temps, vous montrez la décision de votre patron (avant qu'il ne le fasse) sans le contrecoup politique de faire le tour après le fait en disant aux gens pourquoi vous pensez que la décision de votre patron était le mauvais.

Il s'agit d'une situation délicate impliquant une politique du travail, mais elle peut être traitée à l'amiable.

Si votre patron vous dit de faire des tâches stupides, alors vous devriez (aimablement) expliquer pourquoi c'est stupide.

S'il ne comprend pas le point, alors vous êtes obligé de faire des choses stupides. C'est ça. C'est le patron. Dans ce cas, vous pouvez simplement faire ce qu'il / elle dit, ou parler à son patron ou changer d'emploi.

Vous pourriez dire au patron que bien que cela soit techniquement possible, cela coûtera X temps et argent dépensé en efforts pour l'analyse, la conception, la réécriture du code existant, les tests, les tests de régression, ... Et puis demander si la fonctionnalité en vaut la peine . Parfois, la réponse sera "oui! Nous devons l'avoir!", Parfois ce sera "non, je suppose que non".

Si la fonctionnalité demandée viole un principe de base de l'application (comme "Ajouter un bouton bleu!" À une interface utilisateur spécifiée et conçue pour ne comporter que des boutons rouges conformément à la demande du client), je pense que c'est OK demander "Pourquoi?" et mentionner qu'il va à l'encontre de la conception préétablie.

Au final, presque tout est un "peut faire" (il n'est peut-être pas difficile d'un point de vue technique d'ajouter un bouton rouge à une interface utilisateur bleue uniquement), il s'agit plutôt de "devrait faire?"

Pour répondre à votre question modifiée, je pense que la réponse devrait être # 2, "Peut-être", en attendant une enquête et une analyse supplémentaires.

Vous ne voulez pas répondre # 1 "Oui, sans condition", car vous pourriez vous retrouver coincé à vous engager dans quelque chose que vous n'êtes pas en mesure de livrer dans le délai imparti.

Vous ne voulez pas répondre # 3 "Non, c'est trop de travail", car il semble que vous ne soyez pas coopératif et inutilement difficile.

Du point de vue d'un développeur: ne dites JAMAIS à quiconque paie les factures qu'il ne peut pas avoir ce qu'il veut. Au lieu de cela, vous pouvez leur dire qu'ils ne peuvent pas l'avoir à ce prix, ou qu'ils ne peuvent pas l'avoir exactement comme ils l'ont conçu à l'origine.

À votre exemple de "pointeur"; .NET, un environnement de code managé, a des pointeurs. Ils sont indispensables pour beaucoup d'interopérabilité avec du code non managé. Cependant, leur utilisation «sûre» est strictement réglementée et, si elle est utilisée dans un code «dangereux», ce code nécessite des autorisations de sécurité plus élevées lors de l'exécution. Si vous développez un langage géré qui nécessite également un accès direct à la mémoire via des pointeurs, vous pouvez proposer un schéma similaire de marshalling en arrière-plan où vous le pouvez, en utilisant des pointeurs managés en lecture seule où vous ne pouvez pas automatiquement marshaler et en autorisant " vrais "pointeurs uniquement dans les zones les plus fiables de la base de code.

Pour vos exemples d'interface graphique: si vous savez qu'une nouvelle fonctionnalité va "casser" le flux de code actuel, vous pouvez le tester et le développer plus robuste pour annuler tout travail précédent effectué par le flux de travail. Vos clients, et parfois même votre manager, n'ont généralement aucun indice ni intérêt dans la structure du programme; si quelque chose qu'ils veulent est difficile à cause de la façon dont vous avez structuré le programme, alors par définition, la structure est erronée car elle ne vous permet pas de faire ce que le client veut.

Dans tous les cas, cette nouvelle fonctionnalité peut augmenter l'étendue des travaux requis au-delà de ce que le client pensait que ce serait. Cela nécessitera à son tour soit une extension du calendrier, plus d'argent et / ou une réduction des autres travaux prévus.

Cependant, si vous connaissez un moyen d'obtenir le même résultat de base de manière plus simple ou plus logique, cela peut être suggéré au client. Bien qu'ils existent vraiment, je n'ai heureusement pas encore vu un client qui a catégoriquement refusé d'écouter les commentaires des développeurs, en particulier dans un environnement agile où il y a un "propriétaire de produit" dont le seul travail est de se mettre en rapport avec le développement sur divers détails nécessaires tels que celles-ci.

Si vous passez de nombreuses années à programmer de grandes applications et que vous y réfléchissez de manière critique, vous développerez une idée précise du moment où une fonctionnalité va causer des problèmes qui l'emportent sur son utilité. Un autre mot pour cela est la sagesse , et comme c'est le cas avec d'autres types de sagesse, il peut être difficile de faire en sorte que ceux sans elle voient sa valeur.

D'autres affiches ont fait valoir que vous devriez essayer de quantifier le coût du problème qui sera introduit par une caractéristique problématique, et c'est une bonne idée quand c'est possible, mais ce n'est généralement pas le cas. Il est généralement possible d'estimer uniquement les coûts de mise en œuvre immédiats. Même cela est souvent difficile pour de plus grandes fonctionnalités. Quant aux coûts futurs, vous êtes dans une situation difficile. Vous ne savez pas avec certitude quelles autres fonctionnalités seront nécessaires, ni combien de temps le produit sera en maintenance. Le coût sera généralement beaucoup plus élevé que ce que vous pourriez soutenir avec une estimation basée sur des faits concrets.

Plus vous avez démontré de compétence dans le passé, plus vous aurez de marge de manœuvre pour déclarer simplement qu'une fonctionnalité est une mauvaise idée. Cela ne peut venir qu'avec du temps et un succès démontré. Cela dit, vous devez toujours exprimer votre empressement à répondre à la demande, car c'est ce que veut votre client. Vous devez exprimer des réserves en fonction de votre expérience, et une fois que vous l'avez, cela devient un non-problème dans 90% des cas, car vous entamerez une conversation qui va à la racine du problème, à savoir: Pourquoi vous ont-ils demandé d'ajouter cette fonctionnalité en premier lieu? À ce stade, vous pouvez proposer des alternatives, ou peut-être convenir que bien que la fonctionnalité demandée introduise des problèmes, elle est toujours nécessaire.

Bien sûr, il est également possible que vous vous trompiez. Le génie logiciel n'est-il pas amusant?

Puisque la question est assez vague, je vais généraliser un peu avec ma réponse.

Interrogez-les toujours, mais écoutez leur raisonnement. Parfois, les gens oublient simplement le caractère pratique d'une fonctionnalité ou la durée de programmation nécessaire. D'un autre côté, nous nous enfermons parfois dans une mentalité de programmeur d'être efficace / sans fioritures / etc et nous oublions que ce que nous considérons comme non essentiel pour un projet n'est vraiment pas pour le client.

S'ils ont une bonne raison, faites-leur savoir combien de temps il faudrait pour le programmer et toutes les bosses possibles que vous rencontrerez pendant la mise en œuvre et voyez s'ils voudront toujours continuer. Sinon, dites pourquoi vous ne pensez pas que c'est une bonne idée et voyez quelle est leur réaction. Rincez et répétez.

La plupart des choses ont déjà été dites, mais il y a une chose sur laquelle je voudrais insister dans mon environnement de travail actuel. Je travaille pour une entreprise qui est un contractant pour d'autres entreprises et les applications sont liées aux processus métier (à un bon niveau, elles stimulent les ventes et la communication avec les clients).

Les processus commerciaux ainsi que les produits qui les accompagnent peuvent être (au moins si l'entreprise est assez grande) très complexes. Dans une certaine mesure, si vous modélisez une chose complexe, l'application résultante aura une complexité relative. Comme la plupart des gens d'affaires ne voient que leur partie du processus, l'application / le processus complet repose sur une plus grande complexité que ce qui est visible pour un seul utilisateur.

Ce que je veux dire, c'est que lorsqu'une nouvelle exigence commerciale se présente, elle fonctionnera pour les gens d'affaires, car elle n'augmente pas la complexité beaucoup plus, mais peut avoir un impact plus important sur l'ensemble du système. À mon avis, ce n'est pas une raison de s'opposer à ce changement. C'est le bon moment pour discuter des efforts (et des dépenses) avec le client. Cela n'empêchera probablement pas le client d'avoir cette fonctionnalité, mais avec le temps, ils auront une idée des applications et des discussions sur "euh, vous êtes si cher!" sera beaucoup moins difficile.

Je ne sais pas si vous êtes dans une situation comparable, mais j'ai appris que la situation de la partie prenante n'a pas forcément la même complexité imminente que celle que rencontrent les développeurs et architectes du système informatique. Dans cette situation, la communication aide les deux parties.

Excusez-moi, mais cette question ressemble à un mineur qui demande des conseils paternels. Si tel est le cas, le bon développeur devra adopter ces commandements:

• Restez fidèle à vous-même. Si votre instinct vous met mal à l'aise à propos d'une fonctionnalité, exprimez vos préoccupations de manière audible. Les chances sont bonnes que l'équipe n'attende qu'une ouverture.
• N'essayez pas de substituer l'expérience aux règles de base de l'expérimenté. Pour vous, chaque situation est différente, chaque fonctionnalité est nouvelle. C'est un avantage que vos aînés n'ont pas.
• Le développement de logiciels n'est pas une science exacte, il ne le sera jamais. Par conséquent, accumulez la sagesse, pas le comportement.
• Acceptez la défaite. Si l'équipe en décide autrement, ne répétez pas vos préoccupations ad nauseam.
• Penser positivement. Si l'idée demande vraiment de «l'abattre», essayez de lui trouver et de nommer les aspects positifs avant d'énumérer ses lacunes.
• Apprenez à interagir avec les gens. Nous, les développeurs, plaçons souvent la connaissance technique sur la compétence sociale. Les capacités techniques culminent tôt dans la vie, mais la compétence sociale peut continuer à croître jusqu'à la retraite.

Je crois qu'il faut repousser les mauvaises exigences. Mais je crois aussi que lorsque vous avez donné votre meilleur coup pour expliquer pourquoi ils sont mauvais et qu'ils en veulent toujours, alors vous êtes d'accord et faites votre travail.

Par exemple, j'ai eu des gens qui veulent des exigences qui s'excluent mutuellement de quelque chose que l'application fait déjà. Si je fais cela, alors cela sera garanti à 100%. Donc, je renvoie l'exigence et leur dis que cela va enfreindre cette autre règle commerciale que nous avons déjà en place et veulent-ils également changer cette règle? Souvent, le petit groupe qui présente une exigence particulière n'a pas accès à une vue d'ensemble de ce que le reste de l'application peut faire. La plupart du temps, lorsque j'en ai renvoyé un, le client s'est rendu compte que la règle initiale était plus critique et a décidé que le changement qu'il souhaitait n'en valait pas la peine. Quand ils ont décidé de faire le changement, ils l'ont fait après avoir consulté les personnes qui ont poussé l'exigence initiale.

Parfois, le simple fait de poser des questions de clarification leur fera voir que le problème n'est pas aussi simple qu'ils le pensaient. Parfois, vous voulez demander pourquoi ils veulent quelque chose et répondre au véritable besoin qui est à l'origine du changement. Une fois que vous comprenez cela, il est souvent plus facile de voir une solution alternative qui fonctionne pour vous en tant que développeur et répond à leurs besoins. Si vous pouvez présenter cette solution en termes de façon dont elle répondra mieux à leurs besoins que la suggestion d'origine, vous avez considérablement amélioré vos chances de voir votre changement accepté.

Parfois, lorsqu'un changement va créer des ravages à un niveau de base dans votre conception, il suffit de leur donner la nouvelle estimation des heures que le changement prendra pour le désactiver. Si vous combinez cela avec une évaluation des risques qui indique dans quelle fonctionnalité critique vous pourriez introduire de nouveaux bogues en leur disant que cela prendra 6 semaines d'efforts dédiés de 3 personnes, tout à coup ce n'est plus si important.

Mais parfois, vous leur dites que ce n'est pas une bonne idée et pourquoi et ils disent toujours: "Dommage que nous en ayons besoin." Vous en gagnez et vous en perdez et parfois les besoins de l'entreprise ont vraiment changé et l'application doit s'adapter à cela. Une fois la décision finalisée, ce n'est plus le moment de remettre en question ce que vous faites et le temps de continuer à le faire. Si vous avez documenté vos objections, alors vous devriez toujours être bien placé quand il dépasse le budget et provoque de nouveaux bugs plus excitants. Et ils pourraient même être plus disposés à vous écouter la prochaine fois lorsque vous aurez accumulé des antécédents sur ce genre de choses.

La clé pour gagner un grand nombre de ces discussions (personne ne les gagne toutes) est d'abord de se constituer un historique pour savoir de quoi vous parlez. Envoyez ensuite un document écrit qui énonce vos préoccupations (de nombreux gestionnaires sont défavorables au risque, ils sont plus susceptibles de ne pas vouloir que quelqu'un ait un document qui leur prouve le contraire plus tard, donc ils accordent plus d'attention à ce que vous mettez par écrit) et enfin pour s'assurer qu'ils comprennent tous les coûts (pas seulement les heures, mais les risques de sécurité, l'introduction de nouveaux bogues, les délais manquants, etc.) pour effectuer le changement. Le changement n'est pas gratuit et ils doivent le comprendre. La clé suivante est de le faire comme un adulte et non comme un enfant pleurnichard ("mais je ne veux pas l'utiliser ... parce que je n'aime pas ça"). Faites une analyse de rentabilisation pour ne pas le faire et vous obtiendrez beaucoup plus loin en repoussant une mauvaise exigence.

Si je vous ai bien lu, la vraie question porte sur une complexité inconnue. Au départ, j'ai lu votre question comme: "Je vois le risque extrêmement probable d'une complexité excessive, mais pas le patron" Mais vous dites que le patron n'est pas un problème, donc je suppose que vous n'êtes pas sûr des risques d'ajouter une complexité inacceptable sont.

Dans ce cas, je recommanderais une sorte de stratégie d'atténuation des risques. Image que vous envisagez d'ajouter des services WCF / Web à votre API, ce qui pourrait être génial ou beaucoup de complexité sans récompense:

• ajouter la fonctionnalité sur une branche. Si cela fonctionne, fusionnez-le. S'il se transforme en nid de rats, tuez-le.
• lancez un nouveau projet d'une page et faites une preuve de concept. Si vous ne pouvez pas faire une preuve de concept en peu de temps, laissez-la tomber. Si la preuve de concept fonctionne, agrandissez-la et intégrez-la à votre
• parcourez le Web à la recherche de personnes saisissant cette fonctionnalité ou cette technologie. Là où il y a beaucoup d'adhérence, une technologie peut présenter de réels risques de complexité excessive. Java Beans et COM + sont probablement anciens, mais de bons exemples de fonctionnalités qui ont vraiment augmenté la complexité et qui peuvent ou non avoir fourni les avantages de l'équation

Argumentez pas. Discutez éventuellement oui. Mais il doit être traité comme un ajout à la spécification et priorisé avec d'autres fonctionnalités. Si vous savez que la demande ajoutera un temps et une complexité déraisonnables à mettre en œuvre, indiquez-le dès le départ. Pas comme une opposition à la demande, mais comme une explication de ce que vous pensez qu'il faudra pour mettre en œuvre.

Cela dépend beaucoup de la demande. L'implémentation du pointeur est suffisamment grande pour effectuer un projet entier, donc ses mérites doivent être pesés si on leur laisse le choix.

Implémenter un bouton qui rompt le flux. Ce n'est peut-être pas si grave si le formulaire peut être présenté de manière à ce que le bouton soit facultatif. J'ai fait cette chose en fait. J'ai ajouté le bouton mais j'ai également collecté suffisamment d'informations avant que le bouton devienne facultatif. Les utilisateurs qui s'attendaient à ce qu'il soit là l'utilisent et ceux qui se rendent compte qu'il est tout simplement redondant ne le font pas.

Il s'agit d'équilibre et de savoir quand choisir vos batailles. Certaines choses sont plus faciles à mettre en œuvre de toute façon que de traiter les aspects sociaux de ne pas l'inclure.

Le problème que je vois est votre utilisation du mot argument.

Vous devez évoquer les problèmes de conception et le raisonnement derrière eux, mais méfiez-vous parce que les programmeurs ont tendance à se montrer défensifs sur les positions qu'ils ont prises et à argumenter des points juste pour argumenter (Parfois). Je dois m'empêcher d'argumenter un peu - et je ne réussis pas toujours. De plus, en vieillissant, je trouve que je me trompe plus souvent qu'auparavant - ou pire, je ne reconnaissais pas la fréquence à laquelle je me trompais :)

Si vous avez des exigences clairement énoncées (la langue doit être sûre, nous avons besoin de pointeurs pour accéder aux routines héritées), vous pouvez présenter en quoi les deux exigences sont en conflit et demander laquelle est la plus importante. Une fois que vous avez les exigences et les raisons qui les sous-tendent, vous pouvez même être en mesure de trouver une solution complètement différente qui prend en charge les deux exigences (JNI - un peu).

Si ce n'est pas le cas, c'est peut-être le bon moment pour les codifier!

1. Sachez que vous ne savez pas tout et ne pouvez pas tout faire.

2. Si vous êtes sûr que c'est une mauvaise idée, dites ce qui est mauvais.

3. S'ils essaient de vous pousser dessus, dites: - Besoin de plus de temps pour analyser, si vous avez besoin de plus de temps ou dites que nous n'avons pas trouvé de bonne solution à ce problème.

4. S'ils continuent d'insister sur la mise en œuvre de la mauvaise idée, obtenez une reconnaissance d'eux que vous avez déconseillé, y compris vos raisons. Vous pouvez même envoyer un e-mail résumant la discussion avec une copie à votre responsable. Cela pourrait vous sauver un ** plus tard.

Dans un scénario idéal, vous auriez un développeur principal qui prend les décisions finales du côté technique et un chef d'entreprise qui prend les décisions finales du côté commercial. Cela répondrait aux deux questions principales:

1 Quoi? Que veut le client?

2) Comment? Comment pouvons-nous y parvenir d'un point de vue technologique.

Ce que le client veut, c'est le décideur ultime car ce sont eux qui paient les factures

En tant que développeur, vous ne devriez pas vraiment vous soucier des exigences à mettre en œuvre.

Cependant, vous devez expliquer si quelque chose n'est pas réaliste et s'il existe de meilleures façons.

Parfois, c'est la demande réelle du client (issue de la politique interne du client). Ensuite, c'est sans espoir et cela doit être fait (mais la direction doit également se demander si la poursuite de ce projet ou la renégociation des prix doit se faire.)

C'est presque une tâche quotidienne pour moi, et en fait je suis content que ce soit le cas.

Si vous avez la possibilité de donner votre avis sur la question de savoir si certaines exigences doivent ou non faire partie de la demande, des personnes non techniques s'attendront à ce que vous complétiez vos connaissances techniques (par exemple, "l'utilisation de pointeurs rendrait la demande instable" ou "l'utilisation de un paramètre GET pour X est un risque pour la sécurité "). Les boursiers techniques apprécieraient également vos commentaires sur certains avantages ou désavantages spécifiques auxquels ils n'ont peut-être pas pensé.

Bien sûr, c'est dur quand tout le monde veut la fonctionnalité X et vous finissez par dire "ce n'est peut-être pas bon", mais au final, tout le monde essaie de faire une application sécurisée, robuste et stable (maintenable, flexible, etc ... ) et chaque voix devrait compter.

Répondre à votre question, cela ne fait pas partie du travail d'un développeur (c'est-à-dire développer), mais c'est un "extra" qui offre qualité et travail d'équipe.

Si vous êtes en mesure de comprendre les inconvénients de le faire (complexité, manque d'utilisabilité, etc.), il est dans l'intérêt de tous de l'expliquer au mieux de vos capacités. Souvent, les non-développeurs ne comprennent pas les problèmes liés à l'ajout de nouvelles fonctionnalités. C'est facile pour eux car ils n'ont rien à faire ni même y penser.

Cependant, si les pouvoirs en place décident d'ajouter la nouvelle fonctionnalité, vous devez faire le meilleur travail possible. C'est un défi.

Et, si la nouvelle fonctionnalité est trop stupide ou l'environnement de travail trop merdique, il est temps de trouver un autre emploi.