Hoe kan ik een werknemer tegenhouden om het bedrijf te gijzelen?

Wat kan ik doen om deze situatie op te lossen?

Niets, je bent er pas een paar maanden, het is niet jouw rol en je hebt niet de macht om iets te doen, behalve er over te zeuren.

Je superieuren hebben een heleboel recourses, maar hebben ze in 7 jaar niet gebruikt, dus op dit moment ben je gewoon hun redenen aan het raden en een collega aan het analyseren in plaats van je te concentreren op je eigen verantwoordelijkheden en taken.

Huur twee of drie van de slimste ontwikkelaars in die je kunt vinden. Geef ze allemaal de code. Laat ze controleren of ze inderdaad alle code hebben, alles wat nodig is om de software te draaien. Laat ze leren wat de code doet, documenteer het, refactoren het, totdat ze het punt bereiken waar ze problemen sneller kunnen oplossen dan de heer A. Dit alles uiteraard zonder enige kennis van A.

Op dat moment zorg je ervoor dat je de heer A volledig afsluit van alle bedrijfsmiddelen, de taak overdraagt aan je nieuwe ontwikkelaars, en de heer A informeert. A dat zijn dienstverband is beëindigd.

Ik zou denken dat met de ontwikkelmethodes van Mr. A, de hoeveelheid werk die zijn code doet eigenlijk veel minder dan zeven jaar ontwikkeling zou opleveren, en dat de code versluierd is, maar eigenlijk niet moeilijk, wat het werk van de nieuwe jongens een stuk makkelijker maakt.

PS. Vanwege enkele opmerkingen wil ik dit nog eens benadrukken: Het probleem is niet alleen het geld, het probleem is dat de software veel minder goed ontwikkeld is dan het zou kunnen zijn, omdat A zich richt op het moeilijk te ontwikkelen, niet op het verbeteren van de software.

Kort antwoord: Uw organisatie is momenteel in groot gevaar voor The Bus Factor .

Dit is de reden waarom u nooit één persoon alle kennis laat bezitten. Het is een groot risico. Wat zou er gebeuren als deze persoon zou besluiten om te stoppen, of letterlijk geraakt zou worden door een bus? Als de situatie is zoals je het schetst, dan is het hele bedrijf weg. Je moet dit aan je managers melden als een organisatorisch risico, niet als een HR-probleem.

Begin andere mensen over de code te krijgen, met of zonder meneer A. Het liefst zonder, want je hebt hem al geïdentificeerd als het probleem.

Vergeet niet, als meneer A niet wil helpen bij deze risicovermindering voor uw organisatie, dan is hij zelf een gevaar voor de organisatie en moet hij eruit worden gemanaged. Neem zijn macht weg, zodat als hij echt door een bus wordt aangereden, je niet allemaal een weg naar voren hebt.

De andere antwoorden zijn vrij goed, maar er is nog één ding dat ik zou overwegen:

Mijn persoonlijk advies zou zijn om te beginnen met het zoeken naar andere plaatsen om te werken… als het management in 7 jaar geen actie heeft ondernomen, weet ik niet zeker of dit een plek is waar je op de lange termijn voor zou willen werken. Voor mij is dit een waarschuwing voor andere soorten problemen in het bedrijf.

en hij herhaalt slechte beslissingen met opzet om het softwareproduct onstabiel te houden, moeilijk te onderhouden en problemen op te lossen

Dus waarom laat uw team deze “slechte beslissingen” voorbijgaan aan design review of code review? Als u geen code review proces heeft of zelfs maar een design review proces, pleit dan voor een lange termijn.

Maar tot die tijd staat alles wat u moet weten in het Joel op Software blog artikel: Getting Things Done When You’re Only a Grunt

En hij heeft een specifieke oproep om met bozo’s om te gaan: FILE BUGS. Per Spolsky:

Als knorretje heb je als doel schade te minimaliseren, oftewel in te dammen. Op een gegeven moment zal een van deze genieën twee weken lang een stukje code schrijven dat zo ongelofelijk slecht is dat het nooit kan werken. Je bent geneigd om een kwartier lang de tijd te nemen die nodig is om het ding correct te herschrijven. Weersta de verleiding. Je hebt een perfecte kans om deze idioot enkele maanden te neutraliseren. Blijf gewoon bugs rapporteren tegen hun code. Ze zullen geen andere keuze hebben dan er maandenlang op te blijven hameren totdat je geen bugs meer kunt vinden. Dat zijn maanden waarin ze nergens anders schade kunnen aanrichten.

Anders, als een nieuwe aanwinst voor het team, zou je doel moeten zijn om je eigen reputatie van uitmuntendheid te ontwikkelen.

Om het duidelijker te zeggen dan de huidige antwoorden…

Uw probleem :

niemand wist hoe het op te lossen.

Uw oplossing :

• Leer hoe je het zelf oplost.

Daar, nu heeft het bedrijf de andere man niet meer nodig.

Zet dit op de muur: (Je zult een aantal namen en plaatsen moeten veranderen).

Een paar jaar geleden heb ik een week lang een interne cursus programmaontwerp gegeven bij een productiebedrijf in het middenwesten van de Verenigde Staten. Op de vrijdagmiddag was het allemaal voorbij. De DP-manager, die de cursus had geregeld en deze uit zijn budget betaalde, vroeg me naar zijn kantoor. “Wat denk je?” vroeg hij. Hij vroeg me om hem mijn indrukken van zijn operatie en zijn personeel te vertellen. “Behoorlijk goed,” zei ik. “Je hebt daar goede mensen.” Programma-ontwerpprogramma’s zijn hard werken; ik was erg moe; en het advies voor personeelsevaluatie wordt extra in rekening gebracht. Hoe dan ook, ik wist dat hij me echt zijn eigen gedachten wilde vertellen.

“Wat vond je van Fred?” vroeg hij. We denken allemaal dat Fred briljant is. “Hij is erg slim,” zei ik. “Hij is niet erg enthousiast over methodes, maar hij weet veel over programmeren.” “Ja,” zei de DP-manager. Hij draaide zich rond in zijn stoel om een enorme stroomschema aan de muur vast te plakken: ongeveer vijf grote vellen lijndrukpapier, misschien wel tweehonderd symbolen, honderden verbindingslijnen. “Fred deed dat. Het is de opbouw van het brutoloon voor onze wekelijkse loonlijst. Niemand anders dan Fred begrijpt het. Zijn stem zakte naar een eerbiedwaardige stilte. "Fred vertelt me dat hij niet zeker weet dat hij het zelf begrijpt.”

“Geweldig,” mompelde ik eerbiedig. Ik heb het beeld duidelijk. Fred als Frankenstein, Fred de briljante schepper van het oncontroleerbare monsterstroomschema. “Maar hoe zit het met Jane?” Ik zei. “Ik vond Jane erg goed. Ze pikte de ideeën voor het programmaontwerp heel snel op.”

“Ja,” zei de DP-manager. “Jane kwam naar ons toe met een geweldige reputatie. We dachten dat ze net zo briljant zou zijn als Fred. Maar ze heeft zichzelf nog niet echt bewezen. We hebben haar een paar problemen gegeven waarvan we dachten dat ze erg moeilijk zou worden, maar toen ze klaar was, bleken ze helemaal niet zo moeilijk te zijn. De meeste bleken vrij eenvoudig te zijn. Ze heeft zichzelf nog niet echt bewezen — als je ziet wat ik bedoel?”

“Ik zag wat hij bedoelde.”

• Uittreksel uit het boek Software Requirements & Specifications - Michel Jackson (Wellicht de moeite waard om te lezen).

Het antwoord is simpel: ontsla hem. Misschien moet je op korte termijn een niet-triviale hoeveelheid geld uitkeren om de rotzooi die hij heeft gemaakt op te lossen, maar meneer A is niet slimmer dan wie dan ook ter wereld - iemand anders zal de software op korte termijn kunnen onderhouden, en op lange termijn beter kunnen maken.

Er is een perspectief om te overwegen.

Het bedrijf vindt het leuk op deze manier. Als ze het niet 7 jaar hebben laten duren is dat een lange tijd.

We zijn geneigd om als ontwikkelaars te vergeten, dat het niet onze taak is om goede of slimme code te schrijven. Het is onze taak om een product te poofen. Het schrijven van goede code maakt dat proces alleen maar beter, maar je kunt een totaal geweldig product maken met totaal onzinnige code.

Het bedrijf heeft achter zijn beslissingen gestaan, en heeft hem zelfs terug ingehuurd. Ze “vinden” hem en zijn manier van doen “leuk”. Je zult dit waarschijnlijk niet veranderen, zelfs niet als je hem op de een of andere manier ontslagen hebt gekregen. Wat waarschijnlijk wel zal gebeuren is dat ze een nieuwe persoon kiezen om “de man” te zijn en dat het proces opnieuw begint.

Het is niet jouw taak om het bedrijf te leiden. Het bedrijf heeft zijn keuze gemaakt. Je moet de jouwe maken. Leer van de man (hij heeft 7 jaar lang dezelfde baan gehad, hij moet iets goed doen) of ga verder.

Ten goede of ten kwade, noch niets noch niemand is onvervangbaar. (sommigen misschien meer dan anderen, maar toch) Als mensen de oplossing kennen, kunnen ze beginnen met reverse engineering.

Ik stond meer dan een paar keer in jouw schoenen in het verleden. In de meest gelijkaardige situatie als de jouwe, “Mr. A” was al lang weg, maar ik had een monolithische oplossing die werkte voor de achterkant van een kabelbedrijf waar ik geen broncode had voor de lokaal ontwikkelde bibliotheken, en als klap op de vuurpijl was ik een groentje in die industrie.

Ik viel het bijna aan op een modulaire aanpak, met een blik op de bestaande code, reverse engineering waar het ontbrak en het schrijven van modules die om beurten vervangen werden door betere functionaliteit en snelheid kerntaken. Ik heb elke module geperfectioneerd voordat ik naar de volgende ging. In een paar maanden tijd had ik de vorige applicatie om zeep geholpen.

Onvervangbaar zijn wordt overschat.

Ook het omgaan met legacy spullen is geen gemakkelijke taak, misschien doet je collega het wel uit inertie of omdat hij niet beter weet.

Vanuit een zakelijk perspectief zijn er in principe twee oplossingen:

1. 1. Stapsgewijs, met andere woorden, neem een klein stukje van de functionaliteit, herimplementeer het naar een hoge standaard, en zet het in productie, en ga door met het stuk voor stuk te doen totdat het oude systeem volledig uit bedrijf kan worden genomen.
2. 2. Bouw een nieuw systeem volledig op, en ga er dan naartoe, in één keer of geleidelijk, bijvoorbeeld door er nieuwe klanten op te starten en er geleidelijk aan oude klanten naartoe te verplaatsen. Het nieuwe systeem hoeft niet zo functioneel te zijn als het oude; het verkoopargument kan een lagere prijs zijn, snellere ondersteuning, etc.

De voordelen van optie 1 zijn dat er geen grote investering vooraf nodig is, uw nieuwe code wordt geleidelijk aan in het veld getest in plaats van in één keer, en u begint al vroeg voordelen te zien (omdat het bedrijf minder tijd en geld kwijt is aan het onderhouden van de onderdelen van het oude systeem die niet meer actief zijn).

De nadelen zijn echter dat de structuur van het nieuwe systeem sterk beïnvloed kan worden door de structuur van het oude systeem, en in sommige gevallen is het echt moeilijk om delen van een zeer rommelig systeem te vervangen. Soms is een beetje creativiteit nodig - als al het andere faalt, kan je nieuwe code het indrukken van toetsen en klikken op het oude systeem simuleren! Maar interfacing met het oude systeem kan zoveel werk genereren dat het beter is om gewoon te gaan met optie 2.

Hoe dan ook, er is iets dat gedaan kan worden. De vraag is, hoeveel zal het kosten en hoeveel zal het besparen? Proberen te schatten dat voor elk van de bovenstaande opties zal helpen om te bepalen welke optie te kiezen (als die er is). Dit hangt af van de functionele eisen, de structuur van het bestaande systeem en de bereidheid van het bedrijf om geld uit te geven/krediet te gebruiken voor toekomstige besparingen.

Als lid van het softwareteam is het niet uw taak om het bedrijf en zijn werknemers te leiden.

Uw taak is om goede software te schrijven. Dus maak je zorgen over de software, niet over de mensen.

Je ziet de problemen met de software, en uit je vraag blijkt dat je een aantal ideeën hebt om de problemen op te lossen. Breng deze ideeën naar je manager en vecht er voor.

“Manger, deze software is niet getest en de huidige implementatie ervan is niet te testen. Ik stel voor dat we werken aan herimplementatie in een taal die meer testbaar is, met behulp van ontwerppatronen die het makkelijker maken om te testen.”

Nu is het zeer waarschijnlijk dat:

A. Dit is een grote onderneming waar het bedrijf niet in wil investeren, omdat ze de noodzaak niet zien van

B. De heer A zal tegen dit spul pleiten en zal worden geluisterd omdat hij meer senior is

Als dat gebeurt dan heb je geprobeerd je werk goed te doen en werd je gesmoord. Tijd om een nieuwe baan te zoeken.

Als dit uitpuilt en ze naar je luisteren, meld je je aan voor een heleboel werk.

Je kunt niet veronderstellen dat er een intentie achter de situatie zit.

Doelbewust weghouden van moderne softwareontwikkelingsframeworks

Hij is misschien wel het meest comfortabel met wat hij het beste weet?

Ik werkte bij grote bedrijven waarvan de pijplijn een lappendeken van oude en gloednieuwe code was en waar bepaalde stukjes code “gewoon werkten” en nooit werden aangeraakt. Bovendien waren de programmeurs die het schreven al lang weg en begreep niemand echt hoe ze werkten, dus voegden ze gewoon nieuwe functies toe om tegemoet te komen aan de veranderende eisen. Hun pijplijn was altijd live, dus elke grote uitrol kon desastreuze gevolgen hebben (d.w.z. erg duur werk en leveringsonderbreking), dus ze schuwden het te veel aan te raken.

Het is een slechte gewoonte en zorgt voor een ongeoptimaliseerde infrastructuur, maar heeft eigenlijk wel zijn verdienste.

Wat je zou kunnen doen, vooral als je aan veel of alle code moet werken: Als er geen goede documentatie is, stel dan voor om er een te maken (als je weet dat je gekwalificeerd bent en de tijd hebt) of vraag of er een moet worden gemaakt om het werk te versnellen.

Je moet (zoals je al doet) praten over het aanpassen van nieuwe technologieën of verbeteringen met je manager, maar verwachten dat er niets van komt, zelfs als hij het met je eens is.

De kans is groot dat niemand hogerop het voordeel ziet van het uitgeven van middelen hiervoor en uw poging zou kunnen worden gezien als ah, het nieuwe bloed denkt de wereld te kunnen veranderen en ons te leren over de fout van onze manieren.

Helaas verzetten bedrijfsstructuren zich tegen plotselinge veranderingen en zijn moderniseringen een kwestie van het geleidelijk afslijten van de weerstand of het beetje bij beetje doorvoeren ervan, tenzij u kunt laten zien dat uw “revolutionaire veranderingen een gouden eeuw van financieel gewin zonder risico’s zullen brengen”.

Zelfs als hij dit kwaadwillig doet om zijn baan te behouden, zie ik het niet als uw verantwoordelijkheid om het deksel eraf te blazen, zeker niet als uw directe chef hierover geïnformeerd is.

Wat zou u doen? praten met uw manager of zonder hem met het hoger management of met de betreffende collega?

Aangezien je manager besloten heeft de zaak niet te vervolgen zal hij waarschijnlijk niet met zijn leidinggevenden willen praten met of zonder jou, of hij heeft daar al een blokkade opgelopen.

Als je met zijn leidinggevenden praat zonder hem loop je het risico hem te vervreemden.

Praten met de collega zorgt zeker voor een zeer slechte werksfeer achteraf en hij zal zeker elke beschuldiging ontkennen.

De enige manier om dit op te lossen is om Mr. A control.

eerst goedkeuring van het management te krijgen.

Maak een gloednieuwe git.

1. Importeer een goed, afgesproken startpunt.

2. 1. Start vanaf daar, en breng de code naar voren.

3. Geef Mr. A helemaal geen toegang (vertel hem zelfs niet dat het bestaat)

4. 1. Laat meneer A. doen wat hij wil met zijn repo, want je gaat het niet gebruiken.

5. Maak valse codewijzigingen om het actief te laten lijken als dat nodig is om je nieuwe repo voor hem te verbergen.

6. Uiteindelijk zal de code ver genoeg afwijken hij zal automatisch verouderd raken.

Je moet een kritische beslissing nemen om de modules strategie te behouden of te verlaten. Modules zijn niet noodzakelijkerwijs slecht, je moet ze gesynchroniseerd en in orde houden.

Dit zal veel werk zijn aangezien je veel bestaande code moet herschrijven.

Een bijkomend voordeel, is dat de code uiteindelijk ver genoeg zal afwijken dat hij zijn code niet meer kan claimen. Het zal volledig vreemd voor hem zijn.

Wees je ervan bewust dat dit als niet-manager niet je probleem is om op te lossen (behalve het volgen van instructies om dingen te doen die zijn besloten als onderdeel van een oplossing).

Interpreteer ook nooit blindelings “We willen dat probleem XY wordt opgelost” in een verklaring “…vanwege probleem XY”.

Wees je er ook van bewust dat als je eenmaal een initiatief neemt, zelfs met goedkeuring, om de situatie te veranderen, je jezelf in de bedrijfspolitiek betrekt. In de ondernemingspolitiek bestaat er niet zoiets als “een onschuldige innovator zonder persoonlijke agenda, die we niet verantwoordelijk kunnen stellen voor onbedoelde gevolgen”.

Als je het doet, doe het dan met een persoonlijke agenda, en bezit de gevolgen hoe dan ook.

@MightyPizza - Je verspilt je tijd. Ga werken voor een ander bedrijf dat een mooiere en betere toekomst heeft. Je moet alleen zoveel energie besteden aan het oplossen van dit probleem als dit bedrijf je laatste stop is.

Dit is het absoluut beste antwoord dat je gaat krijgen. Bereid je voor op de sprong.

“Ik wil de software modern, onderhoudbaar en stabiel maken.”

De beste manier om dit te doen is op Day One, eerste regel van de code, niet met de hete stapel afval van iemand anders.

Voor hem om zo lang in de positie te zijn gebleven toont het bedrijf is bewust of onbewust het toepassen van Hanlon’s scheermes :

Nooit toe te schrijven aan kwaadwilligheid dat wat adequaat wordt verklaard door domheid.

Het klinkt alsof het zeer moeilijk is om werkelijke gevallen van kwaadwilligheid te vinden, gewoon dingen die niet zo goed hebben uitgewerkt in de loop van de tijd. In feite lijkt het erop dat de heer A mensen heeft laten proberen dingen te veranderen en ze vervolgens heldhaftig heeft laten repareren als ze fout zijn gegaan.

Je moet ook bedenken dat de heer A misschien last heeft van het Dunning-Kruger-effect , in die zin dat hij niet kan zien dat wat hij doet fout is.

Het kan zijn dat hij ooit goed was, maar gestopt is met leren en gestopt is met proberen. Wie weet. Wat je als eerste principe moet nemen, is dat je, hoe erg hij ook is, met hem te maken hebt alsof hij geen kwaadwillende is.

Je vraag lijkt ervan uit te gaan dat hij net achter de baanzekerheid aanzit en weigert dingen te updaten om dit in te bedden. Je hebt misschien gelijk, maar je kunt niet met hem omgaan op deze basis.

Ik weet zeker dat sommige van je slimme ideeën op de weerstand stuiten van “we hebben het een keer geprobeerd en het werkte niet door X.” Vanuit een zakelijk perspectief is dit logisch, ze namen een risico dat iets niet werkte dus waarom zouden ze het opnieuw proberen.

Je noemt als doel.

Ik wil de software modern, onderhoudbaar en stabiel maken.

Laten we dit uitsplitsen naar zakelijke behoefte

1. Modern

Er is geen impliciete bedrijfswaarde in het moderne. Het is in ieder geval aanvechtbaar. Je zegt Java 8, anderen zouden zeggen dat Roest of Golag modern zijn. Zolang een systeem wordt ondersteund is er geen grote waarde in het updaten ervan.

2. Onderhoudbaar

Dit kan ook moeilijk te beargumenteren zijn. Meneer A zal beargumenteren dat het onderhoudbaar is, zoals hij het onderhoudt. Je zou moeten beargumenteren dat de onderhoudskosten drastisch zouden dalen om een grootschalige wijziging van het kader te rechtvaardigen.

3. Stabiel

U zegt dat u het systeem HA wilt maken, maar u zegt ook dat het

de software gebeurtenissen bewaakt, er enige verwerking op doet en dan passende acties onderneemt.

Dat klinkt niet alsof het HA nodig heeft.

*Wat moet je doen? *

Je systeem klinkt als een grote modderbal gedefinieerd door

Een grote modderbal is een lukraak gestructureerde, uitgestrekte, slordige, kanaal-tape-en-balkdraad, spaghetti-code-jungle. Deze systemen vertonen onmiskenbare tekenen van ongereguleerde groei, en herhaaldelijke, doelmatige reparatie.

Het aanpakken van deze kop, met een onwillige ontwikkelaar die dit beheert, zal zeer frustrerend zijn, en waarschijnlijk vruchteloos. Het klinkt alsof vele anderen hebben geprobeerd en gefaald.

Wat je kunt doen is beginnen met het omzeilen:

• Als je het systeem niet HA kunt maken, gebruik dan een berichtenbus systeem of iets dergelijks om de berichten op die manier vast te leggen als het systeem uitvalt verlies je geen data.
• Als je geen unit tests kunt schrijven, schrijf dan systeemtests. Deze zijn niet zo netjes, maar ze zullen het mogelijk maken om te testen op het systeem
• De volgende keer dat er enige actie nodig is, begin dan met het inbouwen van die actie in een onafhankelijk subsysteem dat naar de berichtenbus kan luisteren en zijn eigen actie kan uitvoeren.
• Als je kunt beginnen met het beïnvloeden van sommige downstream effecten (bijvoorbeeld het inkapselen van de acties die worden ondernomen), zet deze dan in een subsysteem.

Er is enig argument om de majectische monoliet te ondersteunen over microservices , maar het gaat ervan uit dat de monoliet goed ontworpen is. In uw geval kan het systeem prima zijn als een goed ontworpen monoliet, maar als het niet goed is ontworpen, moet u de dingen opsplitsen. Deze ziet eruit als een goed artikel om mee te beginnen:

Een meer gebruikelijke aanpak is om te beginnen met een monoliet en de microservices aan de randen geleidelijk af te schillen. Zo'n aanpak kan een substantiële monoliet in het hart van de microservices architectuur laten staan, maar met de meeste nieuwe ontwikkelingen in de microservices terwijl de monoliet relatief rustig is.

Hoewel het belangrijk is om mee te spelen met de heer A, vertel hem niet dat je het systeem vervangt, maar dat je “de betrouwbaarheid verbetert” of dat je redundantie toevoegt. Als je aanvalt wat hij heeft gedaan zal hij het moeilijker maken voor je om je doelen te bereiken.

Je krijgt misschien schilfers dat je het systeem complexer maakt. Het is waar, maar noodzakelijk als je op lange termijn vooruitgang wilt boeken.

Waarom wil iedereen Mr. A zo graag ontslaan? Ik denk dat hij hier niets verkeerds heeft gedaan. Softwareontwikkeling gaat niet over het maken van nieuwe dingen met behulp van coole tools, of een raamwerk. Het gaat over het maken van een stabiel ding dat gewoon “werkt.” Uw bedrijf houdt van Mr. A en is tevreden met zijn werk.

Doelbewust weghouden van moderne softwareontwikkelingsframeworks

Uw systeem is in stabiele staat, dus waarom moet het team zelfs gebruik maken van moderne softwareontwikkelingsframes zoals Scrum of agile?

Geschreven core business logica in talen die niet getest kunnen worden

Is er een vereiste dat de core business logica automatisch getest moet worden?

Opnieuw gearchiveerde software componenten in 30 modules om complexiteit en versiecertificering toe te voegen

Hoeveel meer heeft deze implementatie uw bedrijf gekost?

Ontworpen op een niet-schaalbare manier, zodat er geen HA (high availability) mogelijkheden zijn

Nog steeds dezelfde vraag - hoeveel meer heeft deze implementatie uw bedrijf gekost?

Naar mijn mening is alles wat u hier opschrijft alleen maar uw klacht tegen hem. Als hij veel “vreselijke” dingen had gedaan, zou het systeem zelf in het eerste jaar zijn gesmolten en had hij niet zo lang in uw bedrijf kunnen blijven.

Simpelweg moet het bedrijf hem een royale opslag bieden om de huidige staat van de software en alle kennis die niet gedocumenteerd is te documenteren, dan ontslaan ze hem. Of ze huren een technisch adviesbureau in om alles te documenteren en hij zal het schrijven aan de muur zien en uiteindelijk vertrekken.