Dit is een managementprobleem.

Voordat de kritische code wordt ingezet, moet deze versiegecontroleerd zijn, moet de code worden herzien en moet het gebruik op zijn minst worden gedocumenteerd. Als het gaat om beveiliging, kies dan de juiste reviewers en bescherm de repo en docs. Er is geen reden waarom dit niet onmiddellijk gestart kan worden.

Er is een groter probleem dan werkbeveiliging.

Elk van deze ontwikkelaars zou kwaadaardige code in het bedrijf kunnen plaatsen, hetzij per ongeluk, hetzij om hun eigen redenen. In het slechtste geval zouden ze actief kunnen handelen met behulp van hun zelf gecreëerde situatie (afpersing, sabotage, industriële spionage, etc.). In het beste geval stelt hun ondoorzichtigheid iedereen bloot aan veiligheidsoverwegingen en laat ze altijd een vraagteken achter bij eventuele audits of verantwoordingsplicht. Als er iets misgaat, wie zegt dan dat ze niet op een of andere manier betrokken zijn geweest?

Je moet een rapport opstellen voor het management.

Schrijf een kort document waarin je nauwkeurig uiteenzet waarom de huidige aanpak het bedrijf op een gevaarlijk pad brengt (bijvoorbeeld geraakt worden door een busscenario). Schets de beveiligingsrisico’s, haal misschien zelfs waarschuwingsverhalen aan vanuit uw branche, met verwijzingen naar artikelen, etc.

bevatten ook een lijst van manieren waarop de aanpak van deze man uw eigen werk, maar ook dat van uw collega’s, belemmert.

Ten slotte moet u een lijst met aanbevelingen opstellen die onmiddellijk moeten worden geïmplementeerd, zoals het toevoegen van de code aan versiebeheer voor iedereen, en het draaien van de server op een VM waar iedereen toegang toe heeft. Geef aan hoe deze maatregelen het werk van deze persoon op geen enkele manier mogen beïnvloeden, en zal het hele proces eenvoudigweg veiliger en transparanter maken - _ maak duidelijk dat er geen redelijke bezwaren zijn tegen deze maatregelen._

Misschien ga je met je baas aan tafel zitten als je hem dit rapport overhandigt, en lever je verbaal de exacte angsten op die je hier hebt geschreven: dat deze man zichzelf een imperium opbouwt in de infrastructuur van het bedrijf, en dat hij uiteindelijk potentieel gevaarlijk is. Als uw bazen het gevoel hebben dat deze persoon onredelijk wordt, dan kunt u het advies van @BillLeeper opvolgen en de controle over zijn machine overnemen, zodat hij uw organisatie geen schade kan toebrengen. Dit is natuurlijk aan hen om te beslissen.

Helaas heb je niet echt verteld of iemand met de medewerker of het management over deze zorgen heeft gesproken. Is het echt kwaadaardig? Of is uw collega gewoon blind? Of is het management misschien blind?

Ik ben zelf “die” kerel geweest.

In mijn vorige baan had ik soms verschillende bijzaken om “dit kleine gereedschap te maken” of om iets eenvoudigs te maken. Het blijkt dat er nooit middelen zijn voor interne software… Het ging meestal zoiets als dit:

– Kan iemand kijken naar de oplossingen die ik heb gekozen om te vertellen of het gepast is? – Kom op, we hebben gewoon een eenvoudige tool nodig die deze eenvoudige handeling doet, doe het en het komt goed.

– Kan ik een virtuele server op onze server maken voor dit ding? – Man, het is gewoon voor intern gebruik. Zet het gewoon samen met andere dingen op die kapotte fysieke doos. Of zet het op die doos die we-dunno-wat functies doet. Of zet het op je eigen werkstation.

Natuurlijk, er was nooit tijd om documenten te schrijven. Tenzij ik ervoor koos om het in mijn vrije tijd te doen. Natuurlijk, alles wat ik kon zeggen als sommige tools problemen hadden was “werken aan het”.

En toen heb ik besloten om te stoppen. Dat was het eerste moment dat iemand om me heen zich realiseerde dat de “kleine interne” tools eigenlijk belangrijk waren en dat “eenvoudige” dingen niet zo eenvoudig zijn. Ik bracht een paar weekenden door met het schrijven van dokters om mijn collega’s minder te verneuken. Bijna een jaar is verstreken en ik krijg nog steeds elke maand meerdere telefoontjes over hoe ik iets met mijn interne tools moet doen.

Bewerk

Sommige commentaren hebben me erop gewezen dat ik ze niet gratis moet helpen. Dit is over het algemeen juist. Ik wilde duidelijk maken dat ik niet urenlang bezig ben met het oplossen van hun problemen, maar dat ik slechts een minuut lang bezig ben met het beantwoorden van een vraag. Technisch gezien is het nog steeds waar dat ik op deze manier de bestaande praktijken mogelijk maak en aanmoedig Door de manier waarop het bedrijf mij een deeltijd- of uurloonpositie heeft aangeboden om problemen op te lossen zoals ik eerder heb gedaan en ik heb dit geweigerd.

Het ding is dat ik niet bereid ben om mijn ex-collega’s te dwingen om “beter te onderzoeken” in plaats van me gewoon te vragen “Op welke machine draait de Veeam?” als ik gewoon de naam of het IP-adres kan vertellen zonder na te denken of te zeggen “Het moet worden geschreven in […]”. Naast 2 minuten telefoontje met ex-collega’s is meestal net zo'n positieve en ontspannende afleiding als het bezoeken van stackexchange.

Bewerk einde

Dus wat kan ik voorstellen? Je collega lijkt behoorlijk capabel, nietwaar? Bespreek dit met het management. Zeg niet “hij wordt onvervangbaar”. Vraag het hen gewoon - wat als hij weggaat? Wat als hij voor langere tijd ziek wordt? Overtuig hen ervan dat het probleem echt is. Ze moeten het met die kerel zelf bespreken om oplossingen te vinden. Misschien mist hij gewoon middelen? Misschien heeft hij iemand anders nodig in het “interne software” team om het allemaal leuk en aardig te maken?

De meeste van deze antwoorden zijn WAY OVERBOARD op aangenomen kwaadwillige opzet van de ontwikkelaar in kwestie.

Alvorens een heimelijke afbeelding van de server te maken en vervolgens de man uit het kantoor te duwen, waarom niet even op adem komen en proberen te begrijpen wat er aan de hand is?

Het kan heel goed zijn dat de persoon in kwestie overwerkt is, niet genoeg middelen heeft en meer dan bereid zou zijn om kennis te delen. Of misschien doet hij het al heel lang op deze manier en heeft hij nog nooit een aanwijzing gekregen dat hij anders moet doen. Op zijn minst, zeker als zijn spullen WERKEN, verdient hij een kans om zorgen op te lossen en samen te werken met collega’s.

Ik zie geen bewijs dat dit alles is geprobeerd in de vraag van de OP. Voordat je draconische opties overweegt, moet je eerst proberen te communiceren. Als de persoon niet van plan was schade te berokkenen, kun je van hem medewerking verwachten.

Er is iets dat ik nog niet heb gezien in de andere antwoorden:

Terloops beginnen met het zoeken naar een nieuwe baan

Natuurlijk is dit gebaseerd op de veronderstelling dat je hier al met je manager over gesproken hebt. Andere antwoorden hebben de redenen gegeven waarom dit niet jouw probleem is maar dat van je manager en ze hebben ook aanwijzingen gegeven over hoe je dit gesprek met je manager moet benaderen.

Nu kijk ik naar de situatie waarin je dit met je manager hebt besproken en er na een redelijke tijd niets aan de hand is. Je krijgt het gevoel dat je manager dit niet zo'n groot probleem vindt als je weet dat het is.

Dat is waar je misschien op zoek wilt gaan naar een nieuwe baan. Het maakt niet uit of je manager dit gewoon niet als een probleem ziet of dat hij het gewoonweg niet goed genoeg begrijpt om het probleem te zien, er is hier iets mis. (En ik heb het niet over de “privé” code, maar het probleem dat de manager daar niets aan doet.)

Zo'n probleem is iets wat je waarschijnlijk niet kunt veranderen vanuit de positie van een ontwikkelaar. Er zijn echter andere bedrijven en die hebben niet dezelfde problemen, dus je zou misschien op zoek kunnen gaan naar een andere werkgever.

Als je het van de positieve kant bekijkt, is er op dit moment echter niet al te veel druk op je. Je hebt wel een baan en je verwacht niet dat je die baan kwijt raakt. Je hoeft geen compromissen te sluiten om de huur/hypotheek/woonkosten te kunnen blijven betalen. Je kunt gewoon terloops gaan rondkijken en niet stoppen met je huidige baan totdat je die baan vindt die je echt leuk vindt.

Het lijkt erop dat er hier een aantal goede remedies zijn om dit in de toekomst te voorkomen, maar niet wat er nu aan te doen.

1. Beveilig de computer. Laat het management en een IT-deskundige de machine ontgrendelen en vrijgeven, of eis dat hij de machine ontgrendelt en toegang verleent. Haal dan dit monster van het netwerk. Maak onmiddellijk een beeld van de HD voor het geval hij een dodemansschakelaar heeft.

2. 1. Vuur deze persoon onmiddellijk af. Loop hem de deur uit. Maak je geen zorgen over de oorzaak, er zal genoeg bewijs zijn op die computer van hem. Als het bedrijf zich zorgen maakt, laat hun advocaat zijn magie werken, daar krijgen ze voor betaald.

3. Haal het team bij elkaar. Leg uit wat er gebeurd is. Deze persoon gedroeg zich roekeloos en on-professioneel. Hij bracht het bedrijf in gevaar en werd daarvoor ontslagen. Het gaat alle middelen vergen om deze rotzooi op te lossen.

4. 1. Gebruik het team om dit werk opnieuw op te bouwen en op de juiste manier in te zetten op beveiligde machines etc. Het team zal app voor app moeten doorlopen en de zaken in goede banen moeten leiden. Maak je niet meteen zorgen over het herschrijven, zorg er alleen voor dat er geen achterdeurtjes etc. zijn, en zet dan de diensten op verse, gecontroleerde hardware.

5. Haal een beveiligingsexpert binnen. Deze kerel zal waarschijnlijk niet rustig gaan en zal proberen terug te ‘hacken’ om zijn systeem te saboteren of op een andere manier toegang te krijgen tot zijn systeem. Hij kan ook wereldwijde wachtwoorden hebben voor systemen waarmee hij in de loop van de tijd heeft gecommuniceerd of wachtwoorden van individuen heeft verkregen. IT moet een geforceerde wachtwoord-reset op alle gebruikers activeren en elke toegang van buitenaf voor een tijdje blokkeren (zoals VPN).

Alle huidige antwoorden en de meeste van de huidige commentaren geven alleen de huidige situatie weer of geven suggesties om extreme stappen te nemen.

Gewoon om samen te vatten: Er zijn twee mogelijke situaties: De medewerkers doen dit met opzet, in dit geval zijn ze op een of andere manier kwaadaardig, en dan is uiterste voorzichtigheid geboden. Of de collega’s zien gewoon niet de potentiële en werkelijke problemen en gevaren, die ze veroorzaken, dan zijn ze “vriendelijk”, maar moeten ze wel worden getracht het beter te doen.

Dus, het volgende stappenplan probeert twee dingen tegelijk: 1) Probeer de potentiële schade te minimaliseren, die collega’s kunnen doen, als ze kwaadaardig zijn, en 2) probeer ze in het bedrijf te houden (zodat ze zich kunnen ontwikkelen tot coöperatieve collega’s in de toekomst) als ze vriendelijk zijn:

(btw: Ik weet het, jij bent niet de baas, maar met de informatie die anderen hebben gegeven, denk ik dat je alles in handen hebt om je baas te overtuigen, om deze draad heel serieus te nemen, dus deze routekaart gaat in op wat je baas zou kunnen doen, niet op wat je zou doen. Het enige wat je kunt doen is de aandacht vestigen op je baas. btw2: Als je baas nog steeds niet luistert, zoek dan een nieuwe baan en neem ontslag zodra je een nieuwe baan hebt gevonden. Want die collega’s tikken tijdbommen, of ze nu vriendelijk of kwaadaardig zijn - dat maakt niets uit).

1.) Maak stilletjes back-ups van alles waar je toegang toe hebt. Sluit geen systemen af in het proces, het afsluiten van systemen kan mogelijk een soort boobytraps veroorzaken.

2.) Construeer een reden, dat de werkstations moeten worden afgesloten. Als je een idee nodig hebt, neem dan privé contact met me op.

3.) Haal de harde schijven eruit, maak een volledig beeld, plaats ze terug. Doe dit gedurende een weekend of zo

4.) Als de systemen BIOS niveau inbraakdetectie spul hebben, en je kunt die niet omzeilen, maak dan een andere reden, waarom die inbraakdetectiesystemen worden afgevuurd.

Die collega’s maken gereedschap voor interne spullen, toch? Dus ze hebben geen toegang nodig tot klantensystemen en dergelijke?

5.) Als ze toegang hebben tot systemen, hoeven ze geen wachtwoorden te veranderen, zorg ervoor dat er geen soort van publieke sleutel login is, controleer poorten voor processen die niet-standaard login mogelijk maken. Controleer cron/at jobs, controleer inetd, controleer alles wat momenteel draait. Voor elke pid moet je kunnen antwoorden, waarom dat proces überhaupt draait.

6.) Krijg een nieuwe medewerker (echt nieuw, volledig onbekend. Hij moet echt een goede expert zijn, want hij moet in staat zijn, om hun baan alleen over te nemen voor een maand als het nodig is. Je kunt niet zomaar een willekeurige gediplomeerde student nemen (zelfs niet één met de hoogste graad), je hebt een aantal van die kerels nodig, die nooit een universiteit hebben bezocht, maar toch alles weten) en hem in dat team plaatsen om hen te ondersteunen. Vooral omdat ze blokkers veroorzaken op de andere werknemers, kan het gemakkelijk worden gerechtvaardigd. Zijn officiële taak is om hen te ondersteunen, zijn echte taak is om te leren, hoe ze werken.

Stap 6 is vooral belangrijk, omdat je op deze manier een kans hebt, om erachter te komen, of die collega’s überhaupt kwaadaardig zijn.

Als de nieuwe man goed wordt geïntegreerd in het team, dan kun je ervan uitgaan dat ze vriendelijk zijn, dat die nieuwe man in staat moet zijn om noodzakelijke veranderingen door te voeren zonder dat je die jongens hoeft te vertellen, dat er überhaupt een vermoeden tegen hen is.

Als de nieuwe man erachter komt, dat ze kwaadaardig zijn, maar ze integreren hem, dan is het zijn taak om mee te spelen. Leer alles, vind het cool wat ze doen, en ga zo maar door. Betaal hem twee keer het geld, want hij moet twee keer werken, want als hij eenmaal thuiskomt, moet hij alles wat hij geleerd heeft opschrijven en opsturen naar een of ander nieuw gevormd team dat het werk moet overnemen zodra er genoeg kennis is overgedragen.

Als de kwaadwillenden hem niet integreren, dan is je enige kans om te hopen, je hebt genoeg data geback-upt (alleen voor de zaak) en dat team te ontslaan. Dan heb je misschien twee of meer extra van die superexperts nodig die ik hierboven sprak, om een nieuw team heel snel in die code te krijgen.

Ik hoop dat deze routekaart helpt - in ieder geval als een bron van inspiratie over hoe hiermee om te gaan. Misschien heeft u in uw bedrijf een aantal opties, die ik niet kan overwegen, misschien zijn er wat culturele verschillen, dus u moet hier nog over nadenken en misschien het plan aanpassen.

De betreffende programmeur mag geen nieuw werk krijgen totdat de situatie op een of andere manier is opgelost. Alle nieuwe eisen moeten naar een andere ontwikkelaar/team gaan die de juiste broncontrole en peerreview procedures moet volgen (indien nodig nieuwe medewerkers). De programmeur in kwestie kan bezig gehouden worden met het repareren van defecten of het “blussen” van zijn bestaande nalatenschap. Middelen moeten worden toegewezen om de bestaande legacy te reverse-engineeren en opnieuw te implementeren door middel van de juiste processen. De kosten hiervan moeten worden gerechtvaardigd door het bestaande risico - wat kost het het bedrijf als alles wat deze programmeur heeft gedaan plotseling verloren gaat? Of erger nog, welke bedrijfseigen (bedrijfs)gegevens zijn kwetsbaar voor verlies voor de concurrentie?

Het is misschien de moeite waard om dit aan deze werknemer te vragen: “Wat gebeurt er met ons als je door een bus wordt aangereden of als je besluit een maand lang de wereld rond te varen?” en het antwoord te peilen om te beslissen of hij bereid is zijn code op te geven. Als hij meewerkt, hoeft de situatie niet vijandig te worden; als hij zich geen zorgen maakt over het bedrijf, is het tijd om alles wat hij heeft aangeraakt veilig te stellen.

**

Professionele programmeurs zouden moeten weten dat dit geen manier is om een bedrijf te runnen; en als managers niets anders weten zouden ze dat op zijn minst moeten weten (programmeurs zouden managers en/of managers zouden programmeurs moeten vertellen).

De redenen zijn hopelijk zo bekend dat ik het u niet hoef te vertellen. Ze bevatten “backup”, dat wil zeggen dat je in de problemen zit als je de programmeur verliest (of als ze aan iets anders worden toegewezen), of als de programmeur hun machine verliest.

Je hebt tenminste hebt “company version control” zodat je die strijd niet hoeft te voeren; maak er gewoon een job/proces vereiste van dat het daadwerkelijk wordt gebruikt.

Je moet waarschijnlijk geen productie software draaien op de machine van de ontwikkelaar. Een eerste stap zou kunnen zijn om erop aan te dringen dat:

• Gebruikers maken geen netwerkverbindingen met de machine van de ontwikkelaar
• Software draait op/van een productieserver
• Software draait op de productieserver moet bouwbaar zijn door iemand anders (of door een bouwmachine), van broncontrole

Implementatie die vereist dat de broncode wordt ingecheckt, de bouwinstructies worden gepubliceerd. Ik stel voor dat je dat doet als een semi-noodgeval. Laat de ontwikkelaar geen schrijftoegang tot de productieserver of de bouwmachine (om te controleren of de productiecode bouwbaar is vanuit versiebeheer).

Nadat je dat hebt gedaan (nadat je weet dat de broncode in versiebeheer is en de bouwinstructies zijn gepubliceerd), dan kunnen andere ontwikkelaars nadenken over het inspecteren van de broncode en het helpen onderhouden ervan.

Merk op dat * Get Rid Of Indispensable Programmer As Quickly As Possible ** werd gepubliceerd door Gerald Weinberg in 1971 (dus eigenlijk zou iedereen dit nu al moeten weten). IIRC het originele citaat is,

“Als een programmeur onmisbaar is, zorg dan dat je hem zo snel mogelijk kwijt bent.

Dit is niet jouw probleem, dit is de verantwoordelijkheid en de rol van de managers, je bent gewoon een collega en hebt mogelijk niet alle benodigde informatie. Ik zou me meer zorgen maken over mijn eigen taken dan dat ik betrokken wil raken bij mijn collega’s. Ik zie niet in hoe er iets positiefs uit zou komen als je je collega’s in elkaar zou slaan.

Je maakt een vijand van hem, je laat je manager zien omdat hij incompetent is en geeft de indruk dat je zo weinig werk hebt dat je tijd hebt om interne onderzoeken in te stellen zonder dat je daarnaar gevraagd wordt of bevoegd bent.

De vraag is, hoe graag wil je deze vicieuze cirkel doorbreken? Want laten we hier niet schattig over doen, het gaat de firma kosten.

1. Het bedrijf zal geld moeten uitgeven om iemand in te huren om code te schrijven die het bedrijf controleert.
2. 2. Het bedrijf moet de code van de codeur eisen, en die eis met juridische hulp ondersteunen als dat nodig is. Ik zal er op wijzen dat de code in opdracht van het bedrijf is gemaakt, dat de codeur een loonstrookje van het bedrijf heeft getrokken tijdens het schrijven van de code, zodat de code van het bedrijf is. Het niet produceren van de code door de codeur zou in het slechtste geval worden beschouwd als stelen, wat een strafbaar feit zou zijn.

Vrijheid is niet gratis. Als het bedrijf niet bereid is om middelen uit te geven om vrij te zijn van dit individu, dan is het enige wat je doet je tandvlees te laten wapperen. Jullie zullen allemaal de situatie onder ogen moeten zien, want als de codeur wegrijdt of overreden wordt door een vrachtwagen, dan is het bedrijf SOL.

Denk eens na over de reden waarom ze dit doen. Het is heel goed mogelijk dat er in de bochten wordt gesnoeid om te voldoen aan de tijdsdruk, de prestatiedoelstellingen en de steeds hogere eisen. Dit leidt vaak tot technische schulden en een zeer gestresste codeur die geen andere keuze heeft dan elk probleem van buitenaf op te lossen.

Deze persoon zou wel eens dingen kunnen schrijven op een manier die alleen hij kan oplossen omdat hij niet de tijd heeft om de code tijdig te documenteren, te verbeteren en te onderhouden. Vertrouw me als ik zeg dat dit een grondig negatief effect heeft op iedereen die zich in deze positie bevindt. Het is niet een knuffelrol waar iemand achterover kan leunen en zich kan ontspannen.

Als ze, zoals je titel suggereert, geen problemen oplossen, dan zou er geen probleem zijn. Je zou gewoon de coder weggooien, met al hun code, want die is nutteloos.

Het voorkomen van dit soort situaties is een uiterst elementaire managementtaak. Hieruit volgt dat het management dat zich bewust is van het probleem niet bevoegd is, en het management dat wel bevoegd is, niet op de hoogte is.

Helaas is het ontwarren van dit soort situaties een moeilijke managementtaak. Dus aangezien de managers die verantwoordelijk zijn voor deze ontwikkelaar niet eens in staat waren om de situatie te voorkomen, reken er niet op dat ze in staat zijn om de situatie te verhelpen.

*De enige manier om dit te verhelpen is om te escaleren naar een hoger niveau van het management. * Als ze geïnteresseerd zijn en in staat zijn om dit te verhelpen, hoef je niet eens meer uit te leggen dan je ons hebt uitgelegd - maak het alleen minder persoonlijk door je te richten op de programma’s, en de problemen met hen, in plaats van op de programmeur.

Je moet weten dat dit een hoog risico - lage beloning optie is. Als u dit doet, zelfs als het werkt, zullen de ontwikkelaar en zijn manager (die waarschijnlijk ook uw manager is) eronder lijden, en weten dat u verantwoordelijk bent. Het enige voordeel dat je krijgt door dit te doen is dat je (mogelijk) je eigen code van ethiek en eer volgt, maar je zou je baan kunnen verliezen. Daarom raden sommige van de andere antwoorden aan om het los te laten of om gewoon op zoek te gaan naar een betere baan, wat het slimste is om te doen.

• De andere manier om dit op te lossen is om zelf management te worden, en dit op te lossen, maar er zijn nogal wat valkuilen in het spel.

Na zijn eigen beoordeling heeft hij besloten dat hij geen kans heeft om gepromoveerd te worden, en de enige reden dat het bedrijf hem zou moeten houden is dat hij code achterhoudt voor hen.

Ik weet niet of je het hier mee eens bent, maar als je dat wel doet, zou de code waarschijnlijk door iemand beter gedaan kunnen worden. Of als je niet uitlegt waarom dit gedrag ervoor zorgt dat hij nooit gepromoveerd kan worden.

Ik denk dat het er op aan komt of deze situatie de moeite waard is om het te repareren.

Dit is een taak voor het management. Het eerste management moet proberen te ontdekken of dit opzettelijk is. Als dat zo is, moet er een plan worden gemaakt om de overtreders te ontslaan. Als het niet opzettelijk is, moet er een plan worden gemaakt om de overtreders te trainen.

Ze ontwerpen hun programma’s… zodat ze geleidelijk aan moeilijker te vervangen zijn.

Niet als ik de baas was!

Er zijn hier twee problemen:

1. 1. Slechte programmeur.
2. 1. Incompetent management.

Dit is natuurlijk in de veronderstelling dat je de situatie correct weergeeft.

Je kunt probleem #1 niet oplossen. Er is een kleine kans dat je probleem #2 kunt oplossen. Deze kleine kans is als de baas om bepaalde redenen gewoonweg niet op de hoogte is van wat er aan de hand is. Ga naar de baas, en vertel hem over de problemen die je ziet en waarom ze slecht zijn voor het bedrijf. Dat zal waarschijnlijk mislukken omdat de baas al op de hoogte is van het probleem en niet bevoegd is om het aan te pakken, of zo weinig weet over software en het beheren van software engineers dat hij niet eens bevoegd is om het probleem te begrijpen.

De enige echte oplossing is om te beginnen met het oplossen van probleem #2, waar je in het beste geval een kleine rol in kan spelen. De incompetente manager moet worden vervangen.

De nieuwe manager heeft dan een sit-down met deze programmeur, laat hem de architectuur uitleggen, en vertelt hem om elke nieuwe ontwikkeling te stoppen en alle protocollen te documenteren. In de tussentijd krijgt hij een nieuwe engineer die er is om de eerste engineer te “helpen” met het documenteren van de protocollen, de software in de broncode te zetten en ervoor te zorgen dat de code zelf goed gedocumenteerd is. Deze nieuwe engineer doet elke nieuwe ontwikkeling, en hopelijk worden er fouten opgelost en kleine verbeteringen aangebracht in bestaande software.

De eerste engineer zal dit niet leuk vinden. Hij zou kunnen stoppen, een woedeaanval kunnen veroorzaken, een rumoerig voorwerp kunnen maken, of erger nog, dingen kunnen saboteren. Daarom is het maken van een backup de eerste opdracht. Het zou mooi zijn om een soepele overgang te hebben van de eerste naar de tweede engineer, maar verwacht niet dat dat gebeurt. Het plan is om uiteindelijk de eerste ingenieur te ontslaan, als hij niet eerst ontslag neemt of (nog meer) destructief wordt tegen het bedrijf.

Je kunt deze onzin gewoon niet laten doorgaan. Hoe langer je dat doet, hoe pijnlijker het is om het uiteindelijk te repareren. Het niet repareren omdat het al pijnlijk zal zijn is absoluut de verkeerde manier om hierover na te denken.

In dit geval gebruikte ik de retorische “jij”. Om de vraag te beantwoorden wat je persoonlijk kunt doen, begin je met je zorgen naar de baas te brengen, zoals ik al zei. Nogmaals, dat zal waarschijnlijk niet leiden tot iets nuttigs.

De volgende stap hangt af van dingen die je ons niet hebt verteld. Het kan heel gevaarlijk zijn om over je baas heen te gaan. Als dat zo is, dan is er weinig anders te doen dan te evalueren of je daar echt wilt blijven werken. Als dit een klein genoeg bedrijf is waar je comfortabel kunt praten met het hogere management, ga dan door. Het is best mogelijk dat het hoger management al het gevoel heeft dat de software manager op laag niveau incompetent is, maar dat gaan ze je natuurlijk niet vertellen. Dit zou voor hen de extra informatie kunnen zijn om daadkrachtiger op te treden.

Een andere verre mogelijkheid, als je primaire doel is om deze puinhoop op te lossen en je ziet jezelf een lange termijner op deze plek, is om aan te bieden om zelf een deel van de interne ontwikkeling van de tool op zich te nemen. Dat zou je een legitieme reden moeten geven om met de eerste engineer te praten, te begrijpen hoe de dingen werken, waar de code leeft, enz. Uiteindelijk zou je de tools man en het management kunnen ontdoen van de eerste engineer. Dan kun je ze vragen om iemand in te huren voor die rol, zodat je terug kunt gaan naar wat je wilt doen. Nogmaals, dit is niet iets wat ik serieus suggereer, maar is een alternatief als je echt wilt en bereid bent.