**Avant que le code critique ne soit déployé, il doit être contrôlé par sa version, le code doit être révisé et au moins son utilisation doit être documentée. Si la sécurité est concernée, choisissez les bons réviseurs, et protégez le repo et les documents. Il n'y a aucune raison pour que cela ne puisse pas être commencé immédiatement.

Il y a un problème plus important que la sécurité de l'emploi.

N'importe lequel de ces développeurs pourrait mettre du code malveillant dans l'entreprise, soit par erreur, soit pour ses propres raisons. Au pire, ils pourraient commettre activement des actes malveillants en utilisant la situation qu'ils ont eux-mêmes créée (extorsion, sabotage, espionnage industriel, etc.). Au mieux, leur opacité expose tout le monde à des problèmes de sécurité, et laisse toujours un point d'interrogation sur les audits ou la responsabilité. Si quelque chose tourne mal, qui peut dire qu'ils n'ont pas été impliqués d'une manière ou d'une autre ?

**Rédigez un bref document expliquant exactement pourquoi l'approche actuelle conduit l'entreprise sur une voie dangereuse (par exemple, se faire frapper par un bus). Décrivez les risques de sécurité, et citez éventuellement des mises en garde de votre secteur d'activité, avec des références à des articles, etc.

Incluez également une liste des façons dont l'approche de ce type nuit à votre propre travail, ainsi qu'à celui de vos collègues.

Enfin, assurez-vous de dresser une liste de recommandations à mettre en œuvre immédiatement, comme l'ajout du code au contrôle de version pour que tout le monde puisse le voir, et l'exécution du serveur sur une VM à laquelle tout le monde a accès. Expliquez que ces mesures ne doivent en aucun cas affecter le travail de cette personne, et qu'elles ne feront qu'ajouter de la sécurité et de la transparence à l'ensemble du processus - précisez clairement qu'il n'y a aucune objection raisonnable à ces mesures.

Asseyez-vous peut-être avec votre patron lorsque vous lui remettrez ce rapport, et exprimez verbalement les craintes exactes que vous avez écrites ici : que ce type est en train de se construire un empire dans l'infrastructure de l'entreprise, et que, finalement, il est potentiellement dangereux . Si vos patrons estiment que cette personne peut devenir déraisonnable, alors vous pouvez suivre les conseils de @BillLeeper et prendre le contrôle de sa machine afin qu'il ne puisse pas nuire à votre organisation. C'est à eux d'en décider, bien entendu.

Malheureusement, vous n'avez pas vraiment dit si quelqu'un a parlé de ces préoccupations avec le collègue ou la direction. Est-ce vraiment malveillant ? Ou votre collègue est-il simplement aveugle ? Ou peut-être que la direction est aveugle ?

J'ai été “ce” type moi-même.

Dans mon précédent emploi, j'avais parfois diverses tâches secondaires pour “faire ce petit outil” ou pour faire quelque chose de simple. Il s'avère qu'il n'y a jamais de ressources pour les logiciels internes… Cela se passait généralement de la manière suivante :

– Quelqu'un peut-il regarder les solutions que j'ai choisies pour dire si elles sont appropriées ? – Allez, nous avons juste besoin d'un outil simple qui fait simplement cette simple opération, faites-le et tout ira bien.

– Puis-je créer un serveur virtuel sur notre serveur pour cette chose ? – Mec, c'est juste pour un usage interne. Il suffit de le mettre avec d'autres trucs sur cette boîte physique cassée. Ou le mettre sur cette boîte qui ne fonctionne pas. Bien sûr, il n'y a jamais eu le temps d'écrire des documents. À moins que je ne choisisse de le faire pendant mon temps libre. Bien sûr, tout ce que je pouvais dire quand certains outils avaient des problèmes était “travailler dessus”.

Et puis j'ai décidé d'arrêter. Ce fut le premier moment où quelqu'un autour de moi a réalisé que les “petits outils internes” étaient en fait importants et que les choses “simples” ne sont pas si simples. J'ai passé quelques week-ends à rédiger des documents pour moins ennuyer mes collègues. Près d'un an s'est écoulé et je reçois encore de nombreux appels chaque mois pour savoir comment faire quelque chose avec mes outils internes.

Edit

Certains commentaires ont souligné que je ne devrais pas les aider gratuitement. C'est généralement correct. Je voulais préciser que je ne mets pas des heures de mon temps à résoudre leurs problèmes, je passe juste une minute à répondre à une question. Techniquement, il est toujours vrai que je favorise et encourage ainsi les pratiques existantes. Au fait, l'entreprise m'a proposé un poste à temps partiel ou à l'heure pour résoudre des problèmes comme je le faisais auparavant et je l'ai refusé.

Le fait est que je ne suis pas prêt à forcer mes anciens collègues à “mieux chercher” au lieu de simplement me demander “Sur quelle machine tourne Veeam” si je peux simplement dire le nom ou l'adresse IP sans réfléchir ou dire “Il faut l'écrire en […]”. De plus, un appel téléphonique de 2 minutes avec un ancien collègue est généralement une distraction aussi positive et relaxante qu'une visite à stackexchange.

Edit end

Alors que puis-je suggérer ? Votre collègue semble tout à fait capable, n'est-ce pas ? Discutez-en avec la direction. Ne dites pas “il devient irremplaçable”. Demandez-leur simplement - et s'il part ? Et s'il tombe malade pendant une période prolongée ? Convainquez-les que le problème est réel. Ils devraient en discuter eux-mêmes avec ce type pour trouver des solutions. Peut-être qu'il manque simplement de ressources ? Peut-être qu'il a besoin d'une autre personne dans l'équipe “logiciels internes” pour rendre le tout agréable et joli ?

La plupart de ces réponses sont des réponses “par-dessus bord” sur l’“hypothèse” d'une intention malveillante de la part du développeur en question.

Avant de faire une image subreptice du serveur et de faire sortir le type du bureau, pourquoi ne pas simplement prendre une respiration et essayer de comprendre ce qui se passe ?

Il se pourrait très bien que la personne en question soit surmenée, n'ait pas assez de ressources et soit plus que disposée à partager ses connaissances. Ou peut-être qu'elle le fait depuis longtemps et qu'elle n'a jamais reçu d'indication qu'elle devait faire autrement. Au minimum, surtout si ses affaires MARCHENT, il mérite une chance de résoudre ses problèmes et de collaborer avec ses collègues.

Je ne vois aucune preuve que tout cela ait été tenté dans la question du PO. Avant d'envisager des options draconiennes, essayez d'abord de communiquer. Si la personne n'avait pas l'intention de faire du mal, vous pouvez vous attendre à ce qu'elle coopère.

Il y a quelque chose que je n'ai pas encore vu dans les autres réponses :

Commencez à chercher un nouvel emploi de façon désinvolte

Bien sûr, cela part du principe que vous en avez déjà parlé avec votre manager. D'autres réponses ont fourni les raisons pour lesquelles ce n'est pas votre problème mais celui de votre manager et elles ont également donné des indications sur la manière d'aborder cette conversation avec votre manager.

Maintenant, je regarde la situation où vous en avez parlé avec votre manager et où, après un laps de temps raisonnable, il ne s'est rien passé. Vous avez le sentiment que votre supérieur ne considère pas ce problème comme aussi grave que vous le savez.

C'est là que vous pourriez commencer à chercher un nouvel emploi. Peu importe que votre manager ne pense pas qu'il s'agit d'un problème ou qu'il ne le comprenne pas assez bien pour le voir, il y a quelque chose qui ne va pas ici. (Et je ne parle pas du code “privé”, mais du problème du manager qui ne fait rien à ce sujet)

Un tel problème est quelque chose que vous ne pourrez probablement pas changer du poste de développeur. Cependant, il existe d'autres entreprises qui n'ont pas les mêmes problèmes, et vous pourriez donc chercher un autre employeur.

En regardant les choses du bon côté, cependant, il n'y a pas trop de pression sur vous en ce moment. Vous avez un emploi et vous ne vous attendez pas à le perdre. Vous n'aurez pas à faire de compromis pour pouvoir continuer à payer votre loyer/hypothèque/coût de la vie. Vous pouvez simplement commencer à regarder autour de vous et ne pas quitter votre emploi actuel tant que vous n'aurez pas trouvé celui que vous aimez vraiment.

Il semble qu'il existe de bons remèdes pour éviter cela à l'avenir, mais pas pour le moment.

1. Sécuriser l'ordinateur. Soit la direction et un expert en informatique se rendent sur place lorsqu'il est déverrouillé et sans surveillance, soit ils vont exiger qu'il déverrouille la machine et lui accorde l'accès. Ensuite, retirez ce monstre du réseau. Faites une image immédiate de la HD au cas où il aurait un commutateur d'homme mort.

2. Virez cet individu immédiatement. Faites-le sortir. Ne vous inquiétez pas de la cause, il y aura beaucoup de preuves sur son ordinateur. Si la société s'inquiète, demandez à son avocat de faire son travail, c'est pour cela qu'ils sont payés.

3. Rassemblez l'équipe. Expliquez ce qui s'est passé. Cet individu a agi de manière imprudente et non professionnelle. Il a mis la société en danger et a été licencié pour cela. Il va falloir toutes les ressources dont nous disposons pour régler ce problème.

4. Utiliser l'équipe pour reconstruire et redéployer ce travail de manière appropriée sur des machines sécurisées, etc. L'équipe va devoir passer en revue les applications les unes après les autres et se familiariser avec les choses. Ne vous inquiétez pas tout de suite de la réécriture, assurez-vous simplement qu'il n'y a pas de portes dérobées, etc., puis mettez les services en place sur du matériel neuf et contrôlé.

5. Faites venir un expert en sécurité. Ce dernier ne se laissera probablement pas faire et essaiera de “pirater” son système pour le saboter ou y accéder d'une autre manière. Il peut aussi avoir des mots de passe globaux pour les systèmes avec lesquels il a interagi ou avoir obtenu des mots de passe individuels au fil du temps. Les services informatiques devraient déclencher une réinitialisation forcée des mots de passe pour tous les utilisateurs et bloquer tout accès extérieur pendant un certain temps (comme un VPN).

Toutes les réponses actuelles et la plupart des commentaires actuels ne font qu'exposer la situation actuelle ou suggérer des mesures extrêmes.

Juste pour résumer : Il y a deux situations possibles : Les collègues font cela intentionnellement, dans ce cas ils sont malveillants d'une manière ou d'une autre, et alors une extrême prudence est nécessaire. Ou bien les collègues ne voient tout simplement pas les problèmes et les dangers potentiels et réels qu'ils causent, alors ils sont “amicaux” mais devraient être encouragés à faire mieux. Ainsi, la feuille de route suivante tente deux choses à la fois : 1) essayer de minimiser les dommages potentiels que ces collègues peuvent causer, s'ils sont malveillants, et 2) essayer de les garder dans l'entreprise (afin qu'ils puissent devenir des collègues coopératifs à l'avenir) s'ils sont amicaux :

(btw : je sais, vous n'êtes pas le patron, mais avec les informations que d'autres ont fournies, je suppose que vous aurez tout entre les mains pour convaincre votre patron, de prendre ce fil très au sérieux, donc cette feuille de route traite de ce que votre patron pourrait faire, et non de ce que vous feriez. La seule chose que vous pouvez faire est d'attirer l'attention sur votre patron. btw2 : Si votre patron n'écoute toujours pas, cherchez un nouvel emploi et démissionnez dès que vous en avez trouvé un nouveau. Parce que ces collègues sont des bombes à retardement, qu'ils soient amicaux ou malveillants - cela n'a aucune importance).

1.) Faites des sauvegardes silencieuses de tout ce à quoi vous pouvez accéder. N'arrêtez pas les systèmes en cours de route, l'arrêt des systèmes pourrait potentiellement déclencher certaines sortes de pièges.

2.) Construisez une raison pour laquelle les postes de travail doivent être fermés. Si vous avez besoin d'une idée, contactez-moi en privé.

3.) Extraire les disques durs, faire une image complète, les remettre en place. Faites cela pendant un week-end environ

4.) Si les systèmes ont des trucs de détection d'intrusion au niveau du BIOS, et que vous ne pouvez pas les contourner, construisez une autre raison, pourquoi ces systèmes de détection d'intrusion ont tiré.

Ces collègues créent des outils pour des trucs internes, non ? Donc ils n'ont pas besoin d'avoir accès aux systèmes des clients et autres

5). S'ils ont accès aux systèmes, ils n'ont pas besoin, de changer les mots de passe, de s'assurer qu'il n'y a pas une sorte de connexion à clé publique, de vérifier les ports pour les processus permettant une connexion non standard. Vérifiez les jobs cron/at, vérifiez inetd, vérifiez tout ce qui fonctionne actuellement. Pour chaque pid, vous devez être capable de répondre, pourquoi ce processus fonctionne tout court.

6.) Trouvez un nouvel employé (vraiment nouveau, complètement inconnu. Il doit être un très bon expert, car il doit être capable de prendre en charge seul son travail pendant un mois si cela s'avère nécessaire. Vous ne pouvez pas prendre un étudiant diplômé au hasard (même pas un avec la meilleure note), vous avez besoin de certains de ces gars, qui n'ont jamais visité une université du tout mais qui savent toujours tout) et l'insérer dans cette équipe pour les soutenir. D'autant plus qu'ils provoquent des blocages sur les autres travailleurs, cela peut être facilement justifié. Son travail officiel est de les soutenir, son vrai travail est d'apprendre, comment ils fonctionnent.

L'étape 6 est particulièrement importante, parce que de cette façon, vous avez une chance, de découvrir réellement, si ces collègues sont malveillants du tout. Si le nouveau est bien intégré dans l'équipe, vous pouvez supposer qu'il est amical, qu'il est capable de mettre en œuvre les changements nécessaires sans avoir besoin de dire à ces personnes qu'il y a eu des soupçons à leur égard. Si le nouveau découvre qu'ils sont malveillants, mais qu'ils l'intègrent, son travail consiste à jouer le jeu. Il faut tout apprendre, trouver cool ce qu'ils font, etc. Payez-le deux fois plus, parce qu'il doit travailler deux fois, parce qu'une fois rentré chez lui, il doit écrire tout ce qu'il a appris et l'envoyer à une équipe nouvellement formée qui devrait reprendre le travail dès que suffisamment de connaissances auront été transférées.

Si les malveillants ne l'intègrent pas, alors votre seule chance est d'espérer, vous avez suffisamment de données sauvegardées (juste pour l'affaire) et de virer cette équipe. Alors vous aurez peut-être besoin de deux ou plusieurs autres de ces super experts dont je parlais plus haut, pour intégrer une nouvelle équipe dans ce code très rapidement.

J'espère que cette feuille de route vous aidera - au moins comme source d'inspiration sur la façon de gérer cela. Peut-être que, dans votre entreprise, vous avez des options que je ne peux pas envisager, peut-être qu'il y a des différences culturelles, alors vous devez encore y réfléchir et peut-être ajuster le plan.

Le programmeur en question ne doit pas se voir confier de nouveau travail tant que la situation n'est pas réglée d'une manière ou d'une autre. Toute nouvelle exigence doit être transmise à un autre développeur/équipe qui doit suivre les procédures appropriées de contrôle des sources et d'examen par les pairs (nouvelles embauches si nécessaire). Le programmeur en question peut être tenu occupé à réparer des défauts ou à “combattre le feu” de son héritage existant. Des ressources doivent être affectées à la rétro-ingénierie de l'héritage existant et à sa réimplémentation par des processus appropriés. Le coût de cette opération doit être justifié par le risque existant - que coûtera à l'entreprise la perte soudaine de tout ce que ce programmeur a fait ? Ou pire, quelles données propriétaires (de l'entreprise) sont vulnérables à la perte de concurrence ?

Il pourrait être utile de demander à cet employé : “Que nous arrivera-t-il si vous vous faites renverser par un bus ou si vous décidez de faire un tour du monde en bateau pendant un mois” et d'évaluer la réaction pour décider s'il rendra son code de son plein gré. S'il est coopératif, il n'est pas nécessaire que la situation devienne conflictuelle ; s'il n'y a aucun signe d'inquiétude pour l'entreprise de sa part, il est temps de s'occuper de sécuriser tout ce qu'il a touché.

**Les programmeurs professionnels doivent savoir que ce n'est pas une façon de gérer une entreprise ; et si les managers ne savent rien d'autre, ils doivent au moins le savoir (les programmeurs doivent le dire aux managers et/ou les managers doivent le dire aux programmeurs). Les raisons sont, je l'espère, si bien connues que je n'ai pas besoin de vous les expliquer. Elles comprennent la “sauvegarde”, c'est-à-dire que vous avez des problèmes si vous perdez le programmeur (ou s'il est réaffecté à autre chose), ou si le programmeur perd sa machine.

Au moins, vous avez le “contrôle de version de l'entreprise”, vous n'avez donc pas besoin de vous battre, mais simplement d'exiger qu'il soit réellement utilisé.

Vous ne devriez probablement pas exécuter un logiciel de production sur la machine du développeur. Une première étape pourrait consister à insister sur le fait que :

• Les utilisateurs ne se connectent pas en réseau à la machine du développeur
• Le logiciel s'exécute sur/à partir d'un serveur de production
• Le logiciel exécuté sur le serveur de production doit pouvoir être compilé par quelqu'un d'autre (ou par une machine de compilation), à partir du contrôle des sources

Mise en œuvre qui exige que le code source soit vérifié, les instructions de compilation publiées. Je vous suggère de faire cela en semi-urgence. Ne laissez pas le développeur accéder en écriture au serveur de production ou à la machine de compilation (pour vérifier que le code de production est constructible à partir du contrôle de version).

Après avoir fait cela (après avoir vérifié que le code source est en contrôle de version et que les instructions de compilation sont publiées), les autres développeurs peuvent alors penser à inspecter le code source et à aider à sa maintenance.

Notez que * Get Rid Of Indispensable Programmer As Quickly As Possible ** a été publié par Gerald Weinberg en 1971 (donc, vraiment, tout le monde devrait savoir cela maintenant). IIRC la citation originale est,

“Si un programmeur est indispensable, débarrassez-vous de lui aussi vite que possible.”

Ce n'est pas votre problème, c'est la responsabilité et le rôle des managers, vous n'êtes qu'un collègue de travail et vous ne disposez peut-être pas de toutes les informations nécessaires. Je me préoccuperais davantage de mes propres tâches plutôt que de m'impliquer dans celles de mes collègues. Je ne vois pas comment il serait positif de faire du bruit à propos de votre collègue.

Vous vous ferez un ennemi, vous montrerez votre manager incompétent et donnerez l'impression que vous avez si peu de travail que vous avez le temps de lancer des enquêtes internes sans qu'on vous le demande ou que vous en ayez l'autorité.

La question est de savoir dans quelle mesure vous voulez sortir de ce cercle vicieux. Parce que ne soyons pas mignons, cela va coûter cher à l'entreprise.

1. L'entreprise devra dépenser de l'argent pour engager quelqu'un pour écrire le code qu'elle contrôle.
2. L'entreprise doit exiger le code du codeur, et soutenir cette demande avec une aide juridique si nécessaire. Je précise que le code a été commandé par la société, que le codeur a reçu un salaire de la société pendant qu'il écrivait le code, donc le code est celui de la société. Un manquement de la part du codeur à produire le code serait au pire considéré comme un vol, ce qui constituerait un délit.

La liberté n'est pas gratuite. Si l'entreprise n'est pas prête à dépenser des ressources pour se libérer de cet individu, alors tout ce que vous faites, c'est vous battre les gencives. Vous allez tous devoir faire face à la situation, car si le codeur s'éloigne ou se fait écraser par un camion, l'entreprise est SOL.

Réfléchissez à la raison pour laquelle ils font cela. Il est tout à fait possible que l'on prenne des raccourcis pour répondre aux contraintes de temps, aux objectifs de performance et aux demandes toujours plus nombreuses. Cela conduit souvent à une dette technique et à un codeur très stressé qui n'a pas d'autre choix que de régler chaque problème à la sauvette.

Cette personne pourrait bien écrire des choses d'une manière qu'elle est la seule à pouvoir régler parce qu'elle n'a pas le temps de documenter, de mettre à jour et de maintenir le code en temps voulu. Croyez-moi quand je dis que cela a un effet tout à fait négatif sur toute personne qui se trouve dans cette situation. Il ne s'agit pas d'un rôle pépère où quelqu'un peut s'asseoir et se détendre.

Si, comme votre titre l'indique, ils ne résolvent pas les problèmes, il n'y aurait pas de problème. Vous jetteriez simplement le codeur, avec tout leur code, parce qu'il est inutile.

Prévenir de telles situations est une tâche de gestion extrêmement élémentaire. Il s'ensuit que la direction qui est consciente du problème n'est pas compétente, et que la direction qui est compétente n'est pas consciente.

Malheureusement, démêler des situations comme celle-ci est une tâche de gestion difficile. Donc, puisque les responsables de ce développeur n'ont même pas été capables de prévenir la situation, ne comptez pas sur eux pour la régler.

*La seule façon de régler ce problème est de passer à un niveau de gestion supérieur. * S'ils sont intéressés et capables de résoudre le problème, vous n'avez même pas besoin d'en dire plus que ce que vous nous avez expliqué - rendez la situation moins personnelle en vous concentrant sur les programmes et les problèmes qu'ils posent, plutôt que sur le programmeur. Si vous faites cela, même si cela fonctionne, le développeur et son manager (qui est probablement aussi votre manager) en pâtiront, et sauront que vous êtes responsable. Le seul avantage que vous en tirez est que vous respectez (éventuellement) votre propre code d'éthique et d'honneur, mais vous risquez de perdre votre emploi à cause de cela. C'est pourquoi certaines des autres réponses recommandent de laisser tomber ou de chercher un meilleur emploi, ce qui est la chose la plus intelligente à faire.

*L'autre façon de régler ce problème est de devenir vous-même cadre, et de régler ce problème, mais cela comporte un certain nombre de pièges.

Après sa propre évaluation, il a décidé qu'il n'avait aucune chance d'être promu et que la seule raison pour laquelle l'entreprise devrait le garder était qu'il leur cachait le code.

Je ne sais pas si vous êtes d'accord avec cela, mais si vous l'êtes, le code pourrait probablement être fait par quelqu'un de mieux. Ou si vous n'expliquez pas pourquoi ce comportement fait en sorte qu'il ne pourra jamais être promu.

Je pense que la question est de savoir si cette situation vaut la peine d'être réglée autant que la manière de la régler.

C'est une tâche qui incombe à la direction. La direction doit d'abord essayer de découvrir si cela est intentionnel. Si c'est le cas, un plan doit être élaboré pour licencier les personnes fautives. Si ce n'est pas intentionnel, un plan doit être élaboré pour former les personnes fautives.

Ils conçoivent leurs programmes … de manière à ce qu'ils soient progressivement plus difficiles à remplacer.

Pas si j'étais le patron!

Il y a deux problèmes ici :

1. Mauvais programmeur.

2. Gestion incompétente.

Ceci, bien sûr, en supposant que vous représentez correctement la situation.

Vous ne pouvez pas résoudre le problème n°1. Il y a une légère chance que vous puissiez résoudre le problème n°2. Cette petite chance se présente si le patron, pour certaines raisons, n'est tout simplement pas conscient de ce qui se passe. Allez voir le patron et dites-lui les problèmes que vous voyez et pourquoi ils sont mauvais pour l'entreprise. Cela échouera probablement parce que le patron est déjà au courant du problème et n'est pas compétent pour le résoudre, ou qu'il en sait si peu sur les logiciels et la gestion des ingénieurs en logiciels qu'il n'est même pas compétent pour comprendre le problème.

La seule vraie solution est de commencer par résoudre le problème n°2, dans lequel vous pouvez au mieux jouer un rôle mineur. Le gestionnaire incompétent doit être remplacé.

Le nouveau gestionnaire s'entretient ensuite avec ce programmeur, lui fait expliquer l'architecture, et lui dit d'arrêter tout nouveau développement et de documenter tous les protocoles. En attendant, il fait appel à un nouvel ingénieur qui est là pour “aider” le premier ingénieur à documenter les protocoles, à mettre le logiciel sous contrôle de source et à s'assurer que le code lui-même est bien documenté. Ce nouvel ingénieur effectue tous les nouveaux développements et, espérons-le, les corrections de bogues et les améliorations mineures des logiciels existants.

Le premier ingénieur n'aimera pas cela. Il peut démissionner, piquer une colère, faire du bruit avec un objet ou, pire encore, saboter des choses. C'est pourquoi faire une sauvegarde est le premier ordre du jour. Ce serait bien d'avoir une transition en douceur du premier au second ingénieur, mais ne vous attendez pas à ce que cela se produise. Le plan est de virer le premier ingénieur, s'il ne démissionne pas ou s'il ne se retourne pas (encore plus) contre l'entreprise en premier lieu.

Vous ne pouvez tout simplement pas laisser ces absurdités continuer. Plus longtemps vous le ferez, plus il sera douloureux d'y remédier. Ne pas le réparer parce qu'il sera déjà douloureux est absolument la mauvaise façon de penser à cela.

Dans ce cas, j'ai utilisé le “vous” rhétorique. Pour répondre à la question de savoir ce que vous pouvez faire personnellement, commencez par faire part de vos préoccupations au patron, comme je l'ai dit plus haut. Là encore, il est peu probable que cela aboutisse à quelque chose d'utile.

L'étape suivante dépend de ce que vous ne nous avez pas dit. Il peut être très dangereux de passer par-dessus la tête de votre patron. Si c'est le cas, vous ne pouvez rien faire d'autre que d'évaluer si vous voulez vraiment continuer à y travailler. S'il s'agit d'une entreprise suffisamment petite pour que vous puissiez vous adresser confortablement à des cadres supérieurs, allez-y. Il est tout à fait possible que les cadres supérieurs aient déjà le sentiment que le responsable du logiciel de bas niveau est incompétent, mais bien sûr ils ne vous le diront pas. Ce pourrait être une information supplémentaire qui leur permettrait de prendre des mesures plus décisives.

Une autre possibilité lointaine, si votre objectif premier est de réparer ce gâchis et que vous vous considérez comme une personne à long terme à cet endroit, est de proposer de prendre en charge vous-même une partie du développement interne de l'outil. Cela devrait vous donner une raison légitime de parler au premier ingénieur, de comprendre comment les choses fonctionnent, où vit le code, etc. Au bout du compte, vous serez le spécialiste des outils et la direction pourra se débarrasser du premier ingénieur. Vous pouvez ensuite leur demander d'engager quelqu'un pour ce rôle afin de vous permettre de revenir à ce que vous voulez faire. Encore une fois, ce n'est pas quelque chose que je suggère sérieusement, mais c'est une alternative si vous le voulez vraiment et si vous êtes prêt à le faire.