Je peux comprendre la pression de l'horaire. Vous voulez faire plaisir à vos utilisateurs, car ils sont la pierre angulaire de l'entreprise. Cependant, il est également vrai que certains changements faciliteront les choses à long terme. Malheureusement, la direction de mon organisation a une résistance instinctive à de tels changements et cette résistance est si forte qu'elle empêche des améliorations à long terme.

Par exemple, Apple a récemment introduit le comptage automatique des références pour les programmes iOS. Il s'agit d'une amélioration majeure par rapport aux appels avec rétention / libération manuelle que l'on utilisait auparavant. Le code est plus facile à écrire et à maintenir. Le passage lui-même est susceptible de produire des accidents. Mais une fois que ceux-ci seront résolus, le nombre d'accidents étranges et aléatoires diminuera probablement.

J'ai récemment mentionné à mon patron que je voulais passer au comptage automatique des références. Il a répondu qu'il souhaitait se concentrer sur des améliorations visibles. Il est probable que cette réponse a été motivée par la pression qu'il subit de haut en bas - et probablement du PDG.

Il y a beaucoup d'exemples similaires. Le point commun est que quelque chose doit être corrigé, mais que les coûts à court terme du correctif l'emportent sur les avantages à court terme, où "à court terme" est défini comme "dans les prochaines semaines".

Comment dois-je gérer la situation?

EDIT: Merci pour les réponses. Laissez-les venir. En raison de la pertinence de ma situation, je devrais préciser que mon directeur et le directeur général sont tous deux des programmeurs - même si le directeur général a peut-être déjà oublié comment cela se passe. Apparemment, leurs programmeurs ont été submergés par d’autres pressions.

Vous parlez vraiment de dette technique. Peut-être qu'une métaphore aiderait vos gestionnaires. Je compare souvent l’effet de la dette technique en logiciel à la cuisson dans une cuisine sale. Si l'évier, les comptoirs et la cuisinière sont remplis de vaisselle sale et qu'il y a des déchets sur le sol, la préparation du repas prend plus de temps. Cependant, le moyen le plus rapide de préparer le prochain repas est de contourner le désordre. Nettoyer la cuisine et la garder propre retardera le prochain repas, mais améliorera la livraison de tous les repas suivants. Et tout comme la personne affamée dans la salle à manger ne peut pas voir la cuisine en désordre, et ne comprend pas pourquoi vous voulez nettoyer avant de commencer à cuisiner, votre direction ne peut pas voir le désordre dans le code. Vous devez soit leur montrer le désordre, soit montrer les problèmes de qualité et les retards causés par le désordre.

Peut-être pourriez-vous aussi parler de tâches urgentes et de tâches importantes. Lorsque des tâches importantes ne sont pas terminées, les tâches urgentes prennent plus de temps et coûtent plus cher.

Vous avez trébuché sur quelque chose qui affecte tous les programmeurs à un moment de leur carrière: ce code doit être remanié, il y a des problèmes d'architecture là-bas, ce module est en train de devenir intolérable, etc. En raison de la culture actuelle de votre organisation, on vous force à vous concentrer sur un travail qui ne produit que des avantages directement visibles .

C'est encore le classique Iceberg Secret . Le secret réside dans le fait que, tout comme un iceberg est à 90% sous l'eau, la majorité de tout projet de développement l'est aussi: 90% du travail sera totalement invisible pour l'utilisateur final. Ce code aura un impact sur l'utilisateur final, mais la direction a du mal à comprendre pourquoi vous avez passé six heures à refactoriser les appels de mise à jour / libération et de référencement automatique lorsqu'ils ne peuvent voir aucune différence et que tout fonctionne correctement.

Voici quelques faits que vous pouvez prendre avec vous sur cette question.

• Les gestionnaires, à moins qu’ils ne soient eux - mêmes des programmeurs , ne comprendront pas le secret de l’iceberg.
• C'est un problème d'ignorance, pas de malice. Le PDG veut un bon produit - il ne comprend tout simplement pas tout ce qui entre dans un bon produit.
• Le PDG (et votre supérieur hiérarchique) ne sont pas stupides - étudiez et préparez des faits et des données concrètes expliquant pourquoi vous devriez consacrer votre temps à cela et à d’autres problèmes liés à Iceberg.

N'oubliez pas que vous êtes un homme ou une femme de compagnie. Pas un homme de code. Vous développez ce produit pour une entreprise intéressée par son succès ou son échec - vos projets et propositions de projet doivent en tenir compte. Montrez votre passion pour l'entreprise et le produit, montrez vos connaissances et prouvez à votre patron et à votre PDG qu'ils doivent vous faire confiance lorsque vous venez à eux et leur dire que Something Needs Work fonctionne. Montrez-leur en quoi cela contribuera au résultat final - que ce soit en ajoutant de la valeur au produit (plus de gens achètent des copies) ou en gagnant du temps (moins de clients en colère lorsque votre produit tombe en panne).

Vous pas.

Je vois cette question et toutes les questions du même genre comme une impasse. Vous ne pouvez "convaincre" les gens de rien. S'ils ne sont pas déjà au courant de ce genre de choses ou s'ils n'enquêtent pas, il y a de fortes chances qu'ils ne cèdent pas. Et aucune quantité de données ne les convaincra autrement. Le changement doit venir de l'intérieur. Vous pouvez conduire un cheval à l'eau mais vous ne pouvez pas le faire boire.

Je dis que citez vos modifications souhaitées dans votre prochain devis technique. Soyez comme, hé, nous "devons" mettre à niveau ce nouveau framework introduit par Apple. Ne laissez pas ne pas utiliser ARC figurer sur votre feuille de route. Il n'y a pas d'options. migrer vers ARC est le seul moyen.

J'ai déjà répondu à une question similaire ici, donc cela pourrait être considéré comme un doublon. En gros, vous n'allez pas avoir l'approbation de faire un "effort de refactoring". Pour rendre le code plus propre, vous devez suivre la règle du scoutisme: laissez toujours le code plus propre lorsque vous le quittez que lorsque vous êtes arrivé.

Tout comme rembourser une dette réelle peut sembler une tâche insurmontable (ou nettoyer une maison en désordre). Le truc est de le rendre meilleur morceau par morceau jusqu'à ce que vous commenciez à voir des "îlots de propreté". Une fois que vous aurez pris un élan significatif, les autres développeurs de l’équipe commenceront à remarquer et contribueront éventuellement à la tâche.

Je suggère de lire le Clean Coder de "Uncle" Bob Martin. Écrire un bon code fait partie de votre travail. Vous ne demandez pas la permission de faire votre travail, vous le faites simplement.

Comme pour d’autres questions de cette nature, vous devez fournir des chiffres que la direction comprendra. Chiffres indiquant combien de temps sera économisé en appliquant ces améliorations, combien moins de "collisions bizarres aléatoires" se produiront, etc. Convainquez-les que les collisions sont visibles pour l'utilisateur final et que tout ce qui est fait pour les prévenir est bon pour les affaires.

Vous pouvez également essayer de mettre en œuvre ces améliorations sur votre propre temps (c'est-à-dire en dehors des heures de travail) et ensuite en montrer les avantages à la direction. Je ne le ferais que quand il est clair que la direction ne comprend pas ce que vous essayez de transmettre et / ou qu’elle ne veut pas vous laisser le temps de la tenter.

Bonne chance!

Présenter une analyse de rentabilisation

Les recommandations des ingénieurs sont souvent ignorées pour de nombreuses raisons. La meilleure façon de traiter presque toutes les raisons est de présenter l’analyse de rentabilisation de la raison pour laquelle cela devrait être fait. L'analyse coûts / avantages classique. Cela constitue non seulement un argument convaincant, mais donne également à vos patrons quelque chose à apporter à leurs supérieurs hiérarchiques.

• Quel est le coût initial?
• Quel est le coût en cours?
• Quelles sont les économies d'argent / de temps prévues et d'où viennent-elles?
• Combien de temps faudra-t-il avant de voir le retour sur investissement?

Lors de l'analyse de rentabilisation, vous devez toujours sauvegarder vos arguments avec des données.

• Combien de temps le développement consacre-t-il actuellement aux problèmes que cela éliminerait ou atténuerait?
• Combien de plaintes des utilisateurs avez-vous liées aux problèmes que cela va supprimer ou atténuer?
• Quels sont les autres avantages?

Alignez les nombres et faites-en une équation grossière mais simple. Cela coûtera à X et profitera à la société Y.

Remarque: Ne soyez pas surpris s'il est extrêmement coûteux de mettre en œuvre une bonne idée sur le plan académique.

Ce genre de changement tombe dans la catégorie refactoring. L’approche Agile consisterait à intégrer le temps de refactoring AMPLE à chaque récit que vous estimez et c’est exactement pourquoi. Mis à part les ingénieurs, personne ne comprendra pourquoi vous voulez faire cela et ce n'est pas grave, ce n'est pas leur travail de déterminer comment coder correctement, c'est à vous.

Alors, la prochaine fois que vous aurez du pain sur la planche, assurez-vous que ces changements en font partie. Si vous fournissez des estimations, veillez à ajouter 30% à votre estimation pour la refactorisation. Si vous ne fournissez pas d'estimations, effectuez simplement la refactorisation dans le cadre de votre travail.

Cela peut vous ralentir - eh bien non, ce n'est pas la bonne façon de voir les choses, mais votre vitesse actuelle est une illusion, essentiellement un mensonge que vous faites passer dans la chaîne, vous devriez plutôt être une peu plus lent à cause de ce travail qui, vous le savez, doit être fait.

Vous pourriez probablement construire des maisons plus rapidement si vous n’utilisiez pas le béton comme fondation - et elles sembleraient aussi bonnes au client mais - eh bien - même si le client ne voit pas le besoin de la fondation, le constructeur a besoin de. (Il s’agit en réalité d’un parallèle intéressant car il s’avère que les constructeurs ne font pas toujours ce qu’ils savent qu’ils devraient faire. Nous devons donc adopter des lois pour les y obliger; il n’existe pas de telles lois régissant le développement de logiciels, même si nous sommes confrontés aux mêmes problèmes. décisions et font souvent les mauvaises ...)

Vous dites que vous avez la chance que votre directeur et votre PDG soient tous deux des programmeurs. Ils comprennent donc probablement ce qu'est la dette technique.

Vous devez gérer la situation en essayant de résoudre la situation sur la base de faits, ce qui signifie qu'il est fort possible que vous ne finissiez pas par apporter les améliorations techniques souhaitées (les faits peuvent être agaçants de cette façon).

Votre travail consiste à vous assurer qu'ils comprennent les coûts et les avantages du remboursement de toute dette technique particulière que vous contractez. Leur travail consiste à décider si la meilleure utilisation des ressources consiste à les payer ou à faire autre chose.

Tout comme il peut être difficile pour des personnes non impliquées dans le code de voir les avantages de l'amélioration des éléments "cachés", il peut être difficile pour les programmeurs de voir les avantages des modifications de code visibles lorsque les avantages profitent quelque peu aux secteurs de l'entreprise " caché "des développeurs.

C'est bien si votre direction peut vous expliquer pourquoi les fonctionnalités visibles valent plus que votre temps à payer la dette technique, mais en réalité, ce n'est pas à vous de décider de toute façon. Donc, vous l'expliquer ne fait pas beaucoup pour l'entreprise, sauf vous garder heureux. Et d'une certaine manière, insister pour qu'ils le fassent, c'est ne pas leur faire confiance pour faire leur travail. Si vous n'aimez pas quand ils vous micro-gèrent, alors vous devriez comprendre.

Donc, tant que vous les tenez au courant de l'état de toutes les dettes techniques et des coûts et avantages de les ignorer plutôt que de les rembourser, vous avez fait votre travail. Sauf si vous ne faites pas vraiment confiance à la direction pour faire la leur, dans ce cas, vous avez un problème beaucoup plus important qui serait une toute autre question à résoudre.

Peut-être que ce n'est pas une réponse, mais une réponse basée sur des erreurs que j'ai faites. Également un désaccord avec certaines des philosophies que je lis ici.

• Ne craignez pas que le programmeur sache mieux.
• Être honnête. Re-factorisez au fur et à mesure mais ne mentez pas et ne calculez pas les estimations pour vos propres besoins.
• Vous ne possédez pas le code. N'entreprenez pas de travail non approuvé par le responsable.
• Vous pourriez avoir raison sur quelque chose; vous pourriez vous tromper ... mais vous devriez faire ce que vous êtes payé pour le faire.

Mais suivez certainement les excellents conseils donnés pour améliorer les choses.

Vous travaillez évidemment pour un patron aux cheveux pointus (PHB). Il ne programme plus, si jamais, et s'il l'a fait, il ne serait probablement pas vraiment bon (même s'il aime bien ajouter des phrases telles que "const correct" et "faute de segmentation" pour que les gars sachent qu'il a gagné ses galons ) - c’est comme ça qu’il s’est distingué pour la gestion.

Le PDG (qui a pratiquement un Mohawk) aime le PHB parce que le PHB offre des fonctionnalités . À chaque sprint, il affiche fièrement une nouvelle case à cocher (légèrement décalée, avec une étiquette ambiguë), une icône scintillante (ne fonctionnant pas encore dans n'importe quel environnement mais une couleur 8 bits sur Citrix) et une forme (avec des plantages aléatoires dus aux conditions de course base de données locale implémentée basée sur le C basé sur une variante xml implémentée que personne de l’équipe de dev n’ose toucher, car elle a été écrite par l’un des anciens légendes du dev dev il y a 10 ans et fait TOUT avec des macros avec 5 noms de lettre, qu’ils aient besoin de 5 lettres ou ne pas).

Les programmeurs qui font réellement le "travail" (vous savez ce qui se passe, ce qui est peu pratique après tout le travail réel, comme dessiner des cercles sur des tableaux blancs, crier et manger des Battenburgs miniatures) savent que, dans un système sain , le travail 10 gars, 10 jours à sortir péniblement de la jungle non entretenue, correspondraient probablement à un ou deux jours d’homme, tests inclus. Mais obtenir le système où il est sain d' esprit risque de prendre 6 mois de travail réellement difficile, avec très peu de récompense externe évidente.

Le PHB sait qu’en 6 mois, il pourra intégrer dans l’application trente ou quarante nouvelles fonctionnalités permettant aux vendeurs (qui doivent être des magiciens d’offrir ce qu’ils vendent) de tenter de nouveaux achats et d’améliorer .

Cependant, pour donner sa part au PHB: sans ces cases à cocher et formulaires, les ventes pourraient bien stagner ou baisser, un concurrent pourrait gagner des parts de marché, ce qui pourrait être pire que l’alternative.

La conclusion à laquelle je suis arrivé est que le seul moyen de sortir du bourbier est de travailler dans une nouvelle start-up, avec quelques personnes partageant votre vision de la manière dont les logiciels doivent être conçus, puis s'en tenir fermement à cette philosophie (I travaille encore pour y arriver!)

Il existe un autre coût caché non mentionné dans les autres réponses. À savoir que les bons ingénieurs ont tendance à partir dans le type d'environnement décrit. En fin de compte, quiconque ayant l'ambition ou la capacité de refactoriser a quitté la société, la situation sera alors très pénible, probablement irréprochable. Malheureusement, vous ne pouvez pas dire cela à votre responsable sans paraître arrogant ("Je suis l'un de vos meilleurs programmeurs") et un imbécile perspicace ("Je partirai si vous ne faites pas ce que je veux"). Cependant, n'oubliez pas de le mentionner dans votre entretien de départ, pour vous assurer de ne pas être réembauché.

Vous avez raison et tous les deux tort. C’est pourquoi ces questions perdurent et créent des sentiments durs.

Les raisons pour lesquelles sont clairement énoncées ci-dessus: la direction pense en argent; ou même plus spécifiquement: les revenus. Pour eux, quelque chose qui a un coût mais pas de visibilité directe pour le client n'ajoute pas de revenus, donc c'est un mauvais plan.

Votre vision est également juste: ce sera bénéfique pour les clients mais à plus long terme. Vos actions pourraient générer des revenus encore plus importants à l’avenir par rapport aux plans à court terme.

Vous n'êtes pas le responsable, vous n'êtes pas directement responsable du revenu (je suppose bien sûr). Donc, vous vous mêlez (c'est ce que vous ressentez pour la direction) avec leurs problèmes et vous ne vous concentrez pas sur votre travail: développez davantage le logiciel.

Tous les mots durs et clairs, mais c’est comme cela que la plupart des problèmes se posent, en dehors des erreurs de communication. Vous voulez tous les deux la même chose, mais vos décisions à court terme sont prises différemment. Tout cela parce que le développeur a une perspective différente de celle du manager.

Comment résolvez-vous ce problème? Vous communiquez et vous comprenez assez bien sur un certain nombre de questions. Ce sera probablement l'accent mis sur l'engagement et la satisfaction des clients.

Pour résoudre ce problème de manière stable et future, mettez-vous d’accord sur un point: mesurer le coût de la correction de bogues dans l’ancien code. Mesurez également le temps nécessaire pour utiliser l’ancien logiciel et son utilisation avec la nouvelle base de code.

Pour prouver cela, vous pouvez faire par exemple cette chose très simple: branchez le logiciel dans votre versioning. Tout d'abord, faites ce que la direction veut, alors créez cette fonctionnalité. Vous faites cela, mais l'accord vous donne le temps de montrer la manière différente. Ensuite, faites la même chose dans la nouvelle catégorie, mais corrigez d’abord les problèmes que vous souhaitez résoudre. Ensuite, développez également la solution.

Maintenant, vous avez la même solution mais totalement développé différemment. Créez un dossier à partir de celui-ci, mettez les solutions les unes à côté des autres, y compris des informations de gestion telles que la stabilité, la quantité de code nécessaire et le code lui-même.

Maintenant, prenez un café ensemble et commencez à jeter un coup d’œil, sans vous demander qui a raison, mais quelle serait l’influence des deux directions pour la société. Cela créera une réunion vraiment utile et non pas une discussion meilleure, car cela ne créera pas l’atmosphère dont vous aurez besoin. Cela ne rendra pas votre produit meilleur.

Si vous avez une révision de code, créez un ticket technique indiquant que le code doit être amélioré à l'aide d'ARC et attribué au responsable.

Le convaincre. Expliquez-lui quelques exemples d'améliorations techniques similaires que vous avez apportées et ses avantages pour les projets.

Vous devez vendre ces modifications de la seule manière que la direction est disposée à acheter:

Trouvez une fonctionnalité orientée utilisateur si convaincante que la direction doit la posséder, mais serait impossible à réaliser sans quelques améliorations de bas niveau du code.

Il appartient à votre responsable de s’assurer que l’entreprise concentre son développement sur la fourniture de ce que les clients perçoivent comme une valeur ajoutée. Deux facteurs peuvent modifier cette perception:

1. Combien de temps faut-il pour répondre à une demande client?
2. Livrez-vous quand vous dites que vous allez?

La plupart préfèrent vous dire que cela prendra 6 semaines et que vous livrerez en 5 plutôt que de dire que vous livrerez en 3 mais que vous prendrez 4.

Disposer d'une base de code actuelle plus facile à gérer et à améliorer vous permet de livrer plus rapidement et d'améliorer la prévisibilité. Si vous passez trop de temps à corriger des bogues, vous disposez de moins de ressources pour ajouter de nouvelles fonctionnalités. Évaluez la quantité de ressources consacrées à la correction du code et la précision de vos promesses. C'est un moyen de déterminer si votre code actuel (selon la philosophie de votre patron) coûte trop cher.

Permettez-moi de vous parler d'une opportunité de 2 milliards de dollars qui nous a presque échappé à cause de l'inertie de la direction.

Certains d'entre nous ont à cœur d'écouter la voix du client, c'est-à-dire de comprendre ce qu'il veut. Ce n'est pas toujours ce qu'il demande, mais si vous êtes en mesure d'entretenir des conversations avec votre client, vous finissez par arriver à une compréhension mutuelle de ce qu'il veut. (Ensuite, il peut explicitement commencer à le demander.)

Cela étant dit, il est important de comprendre qui devrait avoir cette conversation avec le client. En règle générale, vos collaborateurs chargés du développement des affaires sont accompagnés de certains concepteurs principaux. Si vous avez un concurrent, vous pouvez vous attendre à ce que le client ait également cette conversation avec lui.

Dans le même temps, il est important que les développeurs se tiennent au courant de leurs domaines, car il y aura une concurrence qui vous battra si vous ne l'êtes pas.

Dans notre cas, nous avions un client existant et un produit quelque peu efficace basé sur une technologie ancienne et le client avait besoin de mises à niveau rapides. Ce dont ils avaient vraiment besoin, c’était d’un produit de remplacement complet, mais l’esprit de notre société était que cela nous obligerait immédiatement à nous positionner, alors que la modification du produit existant permettait à notre client de continuer avec nous sans être légalement tenu de le rendre compétitif. Notre direction pensait qu'ils possédaient ce marché. Le problème était qu'ils ne pouvaient pas suivre les demandes de mise à niveau, car la structure du produit existant n'était pas suffisamment flexible pour effectuer la mise à niveau.

Le client est devenu impatient et a commencé à avoir des conversations avec des sources concurrentes. Nous avons perdu notre "propriété" de ce marché et quelques milliards de dollars de revenus. Cependant, une fois que le marché nous a mis dans une position concurrentielle, la direction n’a eu d’autre choix que de fermer ses portes ou de faire concurrence. (La plupart de ceux qui étaient des barrages routiers ont finalement été licenciés.) Nous avons participé à la compétition et avons pu reprendre l'entreprise par le fil le plus fin.

J'ai dit au début que cette opportunité nous avait presque échappé. Nous avons récupéré l'entreprise pour les revenus que j'ai mentionnés. Si nous avions été plus disposés à nous adapter aux préoccupations du client au début, il n'y aurait pas eu de concurrence réelle.

Voici ce que je vous propose: essayez toujours de rester à la pointe de vos capacités personnelles. Développez toujours un produit flexible et adaptable rapidement aux besoins de vos clients. Si vous travaillez trop longtemps pour une entreprise qui ne pense pas de la sorte, vous vous fanerez et votre motivation personnelle diminuera. Je l'ai vu arriver.

Lorsque vous avez une idée pour améliorer votre produit pour quelque raison que ce soit, posez-vous ces questions: - Est-ce ce que je pense que le client veut? Puis-je valider mes réflexions sur le développement du produit par rapport à la voix du client? Mon entreprise est-elle en mesure de répondre aux besoins de ses clients? Si c'est le cas, comment? - Vous devriez alors être en mesure de présenter des arguments convaincants concernant vos propositions de développement de produits.

Le langage commun des affaires dans tous les domaines et industries est l'argent. Le problème que vous décrivez n'est pas un problème de programmation: c'est un problème commercial. Si vous souhaitez obtenir une réponse appropriée à une proposition commerciale, vous devez l'encadrer dans le langage de l'entreprise. Cela signifie que vous devez être en mesure de présenter un autre plan de projet incluant tous les coûts et avantages.

Vous devez en apprendre davantage sur des aspects tels que les coûts d'opportunité, le retour sur investissement (retour sur investissement) et la valeur actualisée nette (VAN). Vous n'avez pas besoin d'un MBA pour cela, mais vous avez besoin d'accéder à des données qui ne sont peut-être pas disponibles, telles que les coûts de main-d'œuvre, les frais généraux et le potentiel de revenus. Si vous pouvez expliquer clairement qu'un chemin fournira plus de valeur qu'un autre à l'aide de nombres exacts, vous retenez toute l'attention de la direction.

Quand j'étais nouveau développeur dans une très petite équipe, j'ai beaucoup amélioré ce genre de choses pendant mon temps libre. J'ai aimé ça; Je me connectais et essayais de nouvelles techniques intéressantes tout en restant assis dans le salon avec ma femme le soir. Alors que je devenais un développeur plus expérimenté puis un manager d’une plus grande équipe, mon temps libre a disparu. Nous travaillions des heures supplémentaires pour obtenir les fonctionnalités et les correctifs critiques. Il devenait vraiment difficile de justifier de passer du temps à qui que ce soit à ce travail d’entretien ménager régulier, même si nous savions tous à quel point c’était important.

Vos chefs n’ont pas besoin d’expliquer à quel point il est important de réduire les coûts de maintenance, de réduire les coûts de croissance, d’engager une équipe de développement talentueuse, etc. S'ils le font, vous avez de gros problèmes. Ce dont ils pourraient avoir besoin, cependant, c'est d'un plan. En ce moment, je suppose qu'ils ont toutes sortes de plans, d'horaires, de feuilles de route, de promesses et de pressions sur le côté "ajout de fonctionnalités", qui sont en concurrence avec de simples rêves illusoires et des demandes ouvertes de l'équipe de développeurs.

Une chose que vous pourriez essayer est de préparer un plan documenté. Voyez si vous pouvez le lier à des éditions ou quitter les critères de nouvelles fonctionnalités. Une demande de "passer du temps à refaire le comptage de références" peut être difficile à approuver par votre patron, mais il peut être plus facile de programmer un bloc de 5 jours à 4 semaines à partir de maintenant. En gros, peu importe la façon dont vous voyez que les nouvelles fonctionnalités sont planifiées et planifiées, essayez d’en reproduire le sens ou injectez-y une partie «sous le capot».

Commencez petit en demandant 5% de temps alloué à ce genre de choses, puis établissez progressivement vos propres priorités de feuille de route technologique, et continuez à vous attarder pour justifier l'analyse de rentabilisation, le retour sur investissement, les niveaux de risque, etc. Bientôt, vous aurez même un aperçu des défis de vos patrons, car vous trouverez rapidement beaucoup plus d’idées géniales que vous n’avez le temps de faire.

Bonne chance!

Voici pourquoi votre demande de comptage automatique des références est rejetée:

1. Ce n'est pas une amélioration . Une fois que vous avez quelque chose de plus grand que bonjour le monde, tout changement va dans la mauvaise direction. Aucune refactorisation ne changera le fait que si vous devez faire des changements, cela ira toujours dans la mauvaise direction. L'astuce consiste à savoir quand vos modifications sont suffisamment importantes pour que le risque de nouveaux problèmes en vaille toujours la peine. Votre direction a clairement indiqué que si les utilisateurs finaux ne peuvent pas le voir, le risque n’en vaut pas la peine.
2. Le comptage de références est une fonctionnalité complètement folle. Vous avez vu certaines grandes entreprises existantes implémenter certaines fonctionnalités, et vous avez immédiatement pensé que vous aviez besoin de la même fonctionnalité. Eh bien, il est fort probable que votre base de code soit complètement différente de celle utilisée par Apple. Le comptage de références ne va probablement pas fonctionner, ou c'est juste une perte de temps. Vous devriez trouver un moyen différent qui n'exige pas d'étendre les primitives de comptage de références partout dans votre code. Votre plan de refacturation nécessite probablement des milliers de modifications dans la base de code, la plupart de ces modifications ne sont pas nécessaires. Juste une perte de temps et d'argent.
3. Vous résolvez le mauvais problème. La direction sait généralement quels types de problèmes existent dans le système. Un problème de fuite de mémoire non pertinent que la solution de refcounting est en train de résoudre n’en fait pas partie. Concentrez-vous sur de vrais problèmes et non pas sur des problèmes imaginaires liés à la gestion de la mémoire par les ordinateurs.
4. Cela prend trop de temps pour le mettre en œuvre. Apple est un peu plus grand que votre petite équipe avec peu de programmeurs et quelques gestionnaires. Ils peuvent faire de grands changements en payant simplement le prix. S'il faut quelques millions pour mettre en œuvre quelque chose, ce sont des cacahuètes. Si les petites entreprises essaient de faire la même chose, elles vont vite manquer d'argent. Le développement de logiciels est déjà très coûteux. l'ajout de coûts inutiles ne va pas aider un bit. Une fonctionnalité non pertinente telle que la gestion de la mémoire va ouvrir les vannes: après l'avoir approuvée, la moitié de vos programmeurs souhaitent que leur propre "amélioration" soit mise en œuvre. C'est une histoire sans fin et l'entreprise pourrait faire quelque chose d'utile à la place.

Voici quelques étapes que vous pouvez utiliser pour gérer le problème:

1. Déposer la fonctionnalité
2. Découvrez quel est le vrai problème
3. Commencer à faire quelque chose d'utile
4. Planifiez soigneusement la façon dont vous utilisez votre temps
5. Découvrez comment vos améliorations rapportent de l'argent
6. Choisissez uniquement les fonctionnalités qui rapportent le plus d'argent
7. Réalisez que l'aspect programmation du développement logiciel ne représente qu'une petite partie de l'ensemble du système - les améliorations ne seront jamais rentables