Den normala situationen här skulle vara att du samarbetar med kollegor och ledning för att argumentera för fördelarna med att skriva om det, få dina medarbetare ombord, tillhandahålla dokumentation, ge tidsberäkningar, dela upp arbetet och ta itu med det. På det sättet får du inloggningen från chefer först , diskuterar olika problem som ett team och bildar en plan för att övervinna dem. Medarbetare är då mycket mer benägna att vara ombord på projektet som helhet eftersom de hade ett ord att köra det framåt. Om några medarbetare verkligen inte vill göra det vid den tidpunkten, så finns det lite debatt att få, eftersom a) de hade gott om möjligheter att väga in processen och b) den har undertecknats av ledningen som ett överenskommet projekt, så din position är tydlig.

Men i det här fallet verkar det som om du bara har gått vidare och gjort det ensam (eller åtminstone gjort det mesta), potentiellt alienera en annan utvecklare som förstår det gamla systemet perfekt, men som inte nödvändigtvis är bekant med de nya biblioteken, verktyg, tekniker, kodparadigmer och utvecklingsmetoder du använder. Ja, det finns ett bra argument för att säga att han borde ha skickligt och stannade med tiden, men i praktiken kommer det ofta inte att hända.

Du säger då:

Varje konkurrerande programvarutekniker skulle titta på koden och omedelbart gå med mig

... och förlåta mig för att säga, men det verkar ganska ... djärvt. Dessa saker är sällan så svarta och vita.

Särskilt den här delen gör mig nervös:

Medan jag porterade en del av koden har jag hittat många buggar som jag har fixat längs vägen som borde ha undvikits men inte kunde vara eftersom det inte finns något sätt att skriva tester för den gamla koden, och det finns inte heller korrekt felhantering / loggning. Alla tecken pekar på att flytten är en bra idé.

Om det inte finns någon korrekt felhantering, inga enhetstester etc. i den gamla koden, hur kan du verifiera att den beter sig på samma sätt? Hur kan du verifiera att de "buggar" du har åtgärdat inte egentligen var fallhörn, och ingen litade på det beteendet? Hur kan du absolut garantera att du inte kommer att införa några kritiska, brytande förändringar med den nya koden? Ledning och kunder bryr sig inte riktigt hur bra koden är, de bryr sig om att den fungerar. Om det innebär att distribuera det tar längre tid men kunderna är nöjda och inte lämnar, så är det en lönekompensation vad gäller dem.

För att svara på frågan direkt här - du får ledningen på styrelsen genom att visa tidsbesparingarna och producera nödvändig dokumentation och resurser som krävs för att färdigställa den andra utvecklaren och få honom ombord. Det är dock inte snabbt - det är länge & hårt. I själva verket, IMHO hur som helst, borde du börjat närma dig situationen helt annorlunda till att börja med.

Du har ett par problem här relaterade till din brist på kommunikationsförmåga. Jag vet inte hur bra din kod är eller hur dålig den gamla koden är, men låt oss titta på vad du har skrivit här.

1. Försämpa inte andra eller kom från en plats av arrogans

Vad jag behöver göra är att förklara att jag har betydligt mer erfarenhet och har gjort den här typen av arbete tidigare med fantastiska resultat.

Sluta titta på saker som detta. Att vädja till en sådan myndighet kommer inte att vinna någon. Det talar inte om värdet på din kod, det lyfter inte fram några fördelar, det säger bokstavligen bara "Jag tror att jag är bäst på det här så vi gör det på mitt sätt". Allt detta kommer att göra är att pissa dina lagkamrater. Inte vad du vill när du inte har deras buy-in.

2. Lätta på det tekniska språket

Jag blir också fast med att behöva skriva en hel del "dokumentation" som förklarar varför den här nya arkitekturen är bättre, men den är helt teknisk (talar om enhetstestning, beroendeinjektion osv.) så det finns egentligen ingen poäng eftersom ledningen inte förstår det.

Det låter som om din andra lagkamrat inte förstår det, så ändra språket lite . Du behöver det här dokumentet för att inte bara få ledningens inköp utan också inköp från dina lagkamrater. Du pratar om saker som SOLID mycket men din genomsnittliga icke-programmerare (eller till och med äldre programmerare) vet inte vad det är, så använd ordet, förklara vad det är och förklara fördelarna med ramverket. Använd sedan det sparsamt. Gör detta med all teknisk terminologi. Du behöver den här dokumentationen för din chefs inköp

3. Kasta in någon synvinkel för hantering

Jag är en skicklig programvaruarkitekt och det var en lek. Den nya koden är helt enhetstestbar med beroendeinjektion och omfattande loggning, så alla fel och problem är superlätta att spåra.

Sådana saker är bra. Ur teknisk synvinkel. Vad du behöver göra nu är att översätta detta till management speak, som helt enkelt följer upp saker till deras logiska slutsats relaterade till kostnader och retur . Dessa kostnader kan antingen koka ner till pengar eller anställdes tid (eftersom de betalar dig för din tid) Till exempel:

"Jag är en skicklig programvaruarkitekt och det var en bris. Den nya koden är helt enhetlig testas med beroendeinsprutning och omfattande loggning, så eventuella buggar och problem är superlätta att spåra, vilket drastiskt minskar antalet arbetstimmar som krävs för bug-fixing och underhållsarbete, och därmed minskar kostnaderna för dessa arbeten, genom både gör det mycket lättare för utvecklare att hitta den problematiska koden och genom att upptäcka problem med ny kod i nyare versioner innan de når nästa steg i utvecklingslivscykeln. "

Ett antal andra svar här ger också bra pärlor för exempel på detta. Arbeta dessa där du kan och var inte rädd för att komma med mer.

4. Ta itu med din lagkamrats oro

Låt oss nu ta upp din lagkamrats argument för att behålla den ursprungliga koden: 'Det fungerar'. Okej, kanske fungerar det inte alltid men det har förlitats på i några år nu. Du kan föreslå ledningen att ett testsystem körs med din implementering samtidigt med ett annat system som kör den ursprungliga koden. Kanske till och med avfyra några testfall, inklusive några som du förväntar dig att bryta den ursprungliga koden. På det här sättet har din lagkamrat inte längre det argumentet eftersom du har bevisat för alla att din kod också fungerar och till och med fungerar bättre.

5 . Ta itu med ovannämnda (men fortfarande viktiga) faktorer

Låt oss kasta in ett annat argument som lagkamraten kan använda: 'Vi känner alla till den ursprungliga koden'. Detta är lite svårare att skjuta ner eftersom det är entydigt sant, ger en kostnadseffekt som ledningen förstår och inget du kan göra i din kod kan helt lindra detta. Din bästa åtgärd finns i din dokumentation , samma saker som du säger att du är fast i.

Därför måste din dokumentation uppnå två mål:

1) Övertyga hanteringen av fördelarna med din idé (jag pratade om detta tidigare)

2) få dina lagkamrater upp till skrapan (eller åtminstone så mycket som möjligt utan prövning vid eld) på din kod.

Först när du har tagit upp dessa 5 punkter kan du komma runt följande problem:

Problemet är att ledningen ser på oss båda och inte vet vem de ska tro.

Kunderna och ledningen bryr sig inte om något är kodat bra. De bryr sig om huruvida det fungerar i acceptabel grad, de bryr sig om kostnaden och de bryr sig om huruvida de får det i tid.

Det bästa sättet att motivera dina beslut är att förklara i termer av människan. timmar och kostnader.

De tidsbesparande åtgärderna bör tala för sig själva. Om dina ändringar sparar till exempel 2 arbetstimmar per dag, är det 10 arbetstimmar per vecka eller 500 per år. Om vi ​​antar en helt godtycklig siffra på € 25 per arbetstimmar i arbetskostnader, är det 12 500 € sparat per år, vilket kan gå mot mer produktiva uppgifter.

Om dina ändringar innebär en minskning av tiden för att korrigera defekter, det är mer tid du spenderar på att skapa värde för företaget när det gäller nya funktioner som kunderna kan betala för. Kunder betalar inte för buggfixar, de betalar för funktioner. Ju mindre tid ditt team spenderar på att fixa buggar, desto mindre pengar slösar företaget, desto mer pengar tjänar teamet på företaget.

Jag har varit i en liknande situation som din mer än en gång. Vad du tycks sakna är i koden så gammal och rörig, det är verkligen svårt att säga vad som är ett fel och vilken funktion människor är beroende av. Det är också väldigt svårt att se viktiga hörnärenden som har fixats. Din "bråkmakare" är den som har det mesta av den kunskapen.

Det är lite sent nu, men det bästa man kunde göra hade varit att få honom inblandad i testfall redan från början, och fråga honom om varje liten sak som verkar vara en bugg för dig och om alla gränsvillkor. Om du hade gjort detta skulle han vara mycket mer säker på att du faktiskt förstår dessa saker. Kunskap om de "senaste teknikerna" är inte viktigare än domänkunskap. Du behöver båda för att skriva robust programvara.

Du har inte heller något sätt att verifiera att systemet beter sig som det gamla. Skrivtester som körs mot det gamla systemet är långsammare, men låter dig vara mer avsiktlig om vilket beteende du väljer att bevara och vilken bakåtkompatibilitet du väljer att bryta.

Så få honom inblandad i dessa saker nu, att i möjligaste mån. Ju mer input du kan få från honom, desto bättre blir resultatet och desto bättre kommer du att få en allierad.

Visa, säg inte

Detta är axiomatiskt för att skriva, men med all ärlighet är det axiomatiskt också för arbetsplatsen. Prata inte [teorier] om de förbättringar du gör, visa hur de är [implementerade] förbättringar. Jargong är ett bra sätt att genväga en annars ordlig beskrivning av vad en viss struktur är när man pratar med en annan domenexpert, med tanke på att andra domenexperter förstår vad det översätter till, men jargong är också ofta något som människor som själva inte gör faktiskt förstår vad de pratar om gömmer sig bakom. Det är också en fara när man pratar med någon som inte "talar" samma jargong, eftersom det kan uppstå anspråksfullt eller som avsiktligt förvirrande, eller till och med som ett misslyckande med att förstå projektets behov som helhet (särskilt i förhållande till bredare affärsmål) kontra synen från en enskild medlems perspektiv på vad som i själva verket bara är en uppsättning möjliga verktyg för att arbeta med det projektet.

Om du har gjort faktiska, deterministiska förbättringar är de också mätbar .

Detta går utöver bara mjukvaruutveckling och är något du alltid bör ha fokus på när du gör några arbetsplatsprojekt.

När du lägger ett projekt, det är bra att diskutera saker som är konceptuella eller framställningar baserade på dessa begrepp (men du bör helst ha utgångsdata för att visa varför status quo kan vara ett problem som behöver lösas, istället för att bara sätta lösningar på något som inte är klart ett problem).

När du försvarar en proje ct, du vill kunna visa att det finns faktiska förbättringar som uppnås eller har uppnåtts. Detta är språket på metanivån i själva projektet / verksamheten, snarare än bara tekniskt verktygsspecifikt samtal som inte i stor utsträckning förmedlar importen av de metoder som används och de val som görs.

Helst har du data, och den starkaste informationen är längsgående med liknande jämfört med liknande (så väl som möjligt kan göras)

Hur du vill närma dig detta om du hade data före dina ändringar är upp till dig. Helst skulle du jämföra något som håller saker och ting i stort sett rättvisa och inte kommer att bero på ojämnheter av slumpmässighet.

Samtidigt när vi diskuterar fel brukar fel inte drabbas av något slag på ett tillförlitligt och repeterbart sätt, inte heller är alla fel lika, så det här kommer alltid att vara ett problem när man gör jämförelser mellan före och efter.

För något liknande här är några saker som kan användas men måste ha en viss uppmärksamhet på att utan en tillräckligt lång tid för statistisk signifikans (och ett sätt att avgöra vad som utgör det i det här fallet) så spelar du i nivå med siffror:

• Tid från första rapportrapporten till att hitta var problemet ligger inom källkoden
• Tid från att hitta platsen till problemet till att uppnå en korrigering
• Genomsnittlig tid för att lösa rapporterad bugg
• Genomsnittligt antal buggar loggade per rimligt inramat tidsfönster [vecka / månad / kvartal]
• Genomsnittligt antal utvecklade timmar per resonemang inramat tidsfönster som arbetar med buggar

Du kanske inte har tillgång till alla dessa, men din chef eller projektledaren för detta kan.

Eftersom detta inte är 't något där data kommer att vara konsekventa, ett annat tillvägagångssätt du kan ta är att hitta jämförbara enskilda incidenter både före och efter förbättringarna (mycket liknande felmodaliteter / etc), och skapa fallstudiejämförelser. Gå igenom fixprocessen i varje fall, den tid det tar vid varje steg osv.

Liknande saker kan också göras för ändringar relaterade till funktionsförbättringar, om din omarkitektur lyckades. Tänk på att du vill visa upp aspekter som minskar fel framför och sparar därför tid på lång sikt. Om möjligt visa antalet fel som uppstått vid en tidigare funktionstillägg eller liknande förändring, de relaterade genomsnittliga tidskostnaderna, och sedan visa hur de kanske högre kostnaderna i förväg med den nyare metoden lönar sig över tiden. Prata inte bara om relaterade teorier. Visa dem som tillämpade i sitt sammanhang.

Lyft upp, tryck inte ner

Jag tänker inte göra antaganden om hur du har varit kommunicera med andra om detta, men det är ganska tydligt att du har lyckats trampa på minst en uppsättning tår. Det här handlar inte om fel men det handlar om att hitta positiva sätt att antingen gå framåt eller åtminstone mildra situationen.

Detta är kanske den verkliga bakomliggande frågan du är nu kommer att stå inför.

Det är lätt att hitta situationer som denna extremt irriterande och stressande. Även om det inte nödvändigtvis är rättvist, är det bästa sättet att komma framåt vanligtvis att vara lugn och bara tala mot framåtblickande positiva saker snarare än dålig mun, särskilt när det gäller tidigare arbete. Förnedra inte det tidigare arbetet, kalla det inte för att vara föråldrat, bara prata om de påvisbara effekterna av dina förbättringar.

Ibland kommer du att göra fiender från gör bra arbete, och du kan inte kontrollera detta. Vad du kan göra är att försöka komma ut och se ut som om du har hanterat det lugnt och moget och varit den som sträcker sig fram och försöker dra upp snarare än att den som står där är en ryck om det. / p>

Det bästa tillvägagångssättet är, när det är möjligt, att rekrytera personer som kan skapa problem till din sida i förväg. När saker har börjat gå nedförsbacke blir det svårt eller omöjligt: ​​den ideala tiden är i förväg. Visa dem , individuellt och ur deras perspektiv, hur detta både kommer att göra deras liv enklare, inte göra deras liv svårare (igen, försiktig med jargong, även om man pratar med någon annan i ditt yrke när det gäller detta), och förhoppningsvis involvera några saker som de till och med kan hitta spännande. Detta kräver att man faktiskt förstår dem till en viss grad. Ta reda på vad deras oro faktiskt är (utanför en gruppinställning) och både lindra dem och visa hur detta kommer att bli en förbättring för dem , inte bara för verksamheten / projektet .

Helst handlar det inte bara om dig själv, det är den typ av sak där vi förhoppningsvis alla vill att alla omkring oss ska ha en bra arbetsupplevelse och vara lyckliga.

Observera att detta inte alltid är möjligt. Men åtminstone i gruppinställningar, hur du komporterar dig själv är något du har en viss kontroll över, så det är dags att inte prata ner till någon, inte förakta någon annans arbete (eller bekymmer, eller perspektiv eller faktiska klagomål), och fokusera bara på dina positiva.

Om någon tar upp problem, använd dem som en ledpunkt för hur det var "en bra punkt att ta upp" eftersom du vill ta itu med hur detta kommer att vara en förbättring i samband med dessa problem. avvisa inte bekymmerna. Ogiltigförklara inte problemet med oro. Hitta en positiv, framåtblickande vinkel. Tappa inte ner detaljer om saker blir alltför avspårade, det är ok att säga att du gärna kommer att gå in mer detaljerat separat när det gäller en viss oro, men för närvarande vill du försäkra dig om att de bredare bildaspekterna av det som berörs, saker behandlas väl. Planera ett relaterat möte på plats vid behov. Uppskjuta alla relaterade avspårningar till det mötet. Du måste antagligen se till att den som övervakar både dig och den här personen kommer att gå med på detta i förväg (och du vill definitivt inte göra något liknande utan att de är närvarande).

Det här är ett tillvägagångssätt du kan ta för att komma ut och se ut som någon som får saker gjorda och också hanterar oenigheter på arbetsplatsen produktivt snarare än att skapa huvudvärk för alla ovanför dig. Helst är det inte bara hur du ser ut, utan det blir faktiskt fallet.

En slutlig övervägning är att när du gör saker som kan tolkas för att få någon annan eller deras arbete att se dåligt ut, ta dig tid att lyfta fram allt det goda de har gjort, hur det positivt påverkar eller underlättar ditt arbete och hur du bara står på deras axlar för att ta ett steg framåt. Idealiskt, involvera dem i detta: be dem diskutera någon relaterad aspekt, eller bättre än att förklara en given detalj. Ge dem utrymme att fortsätta se bra ut i förhållande till vad du gör, även om mycket av det kan ses som att de tar bort deras kod . Hitta sätt att ändra perspektivet på detta så att det inte handlar om att bli av med deras arbete.

Bredare bildreflektion

En sak att gå tillbaka och överväga är att om du har en kollega som inte följer mer moderna metoder men som i huvudsak har varit dedikerad till projektet, kanske du inte når de affärsmål som du tror att du är. / p>

Visst, ur ditt perspektiv är detta slöseri med pengar. Det kan vara. Det kanske inte är. Dina bekymmer om hur mycket de är eller inte fungerar ur ditt perspektiv är anmärkningsvärda, men beroende på din position kanske du inte har en bredare bild i förhållande till detta. Ingen är individuellt otillgänglig, men ibland finns det balanser som är inblandade i att ersätta någon där det inte är värt att göra det, men där minskningen av arbetsbelastningen på den personen inte frigör dem för något annat meningsfullt, vid vilken tidpunkt relaterade resurser spenderas bättre någon annanstans snarare än att förbättra vad de har tilldelats / fokuserat på.

Det är inte något jag personligen håller med om, men det är värt att vara medveten om att det ibland står bredare politiska verkligheter på spel och upprör det ganska stabila världar av vissa människor kan spara lite pengar men det är kanske inte värt att göra från andra synvinklar. När du gör detta måste du vara beredd att visa betydande besparingar. Och helst måste du kunna göra det utan att få någon annan att se dåligt ut eller på annat sätt göra dem till din fiende under processen.

Programvara förekommer inte utan människor. Programvara är inte användbar förutom i hur den fungerar som ett verktyg för människor. Detsamma gäller utvecklingsarbete. Ja, det handlar om att berätta för datorn vad den ska göra. Men det handlar också om lagarbete och kommunikation. Jag skulle säga att det viktigast av allt handlar om lagarbete och kommunikation .

De flesta av programvaruutvecklingsprinciperna du tar upp handlar i grund och botten om verkligen om att skapa konsekventa ramar som serverar lagarbete, kommunikation (även när du arbetar individuellt är det sant, eftersom det handlar om att kommunicera med ditt framtida jag) och grundläggande verkligheter av mänsklig felbarhet. Du har förlorat kommunikationen med medlemmar i ditt team och denna friktion har varit ett resultat. Det är lätt att avfärda "arbetsplatspolitik" som något som människor "inte borde behöva ta itu med för att få saker gjorda" men egentligen, vad det egentligen betyder är att vi behöver kommunicera med varandra för att gå vidare som ett team. Helst är detta rollen för någon som leder teamet. Men verkligheten är att om du vill vara någon som får saker gjort och gör betydande positiva förändringar, måste du hantera förväntningar och kommunikation med dina kollegor också. Du kan få din chef på din sida om detta, men du kan inte bara begrava huvudet i sanden för att det är nödvändigt och låtsas att de bara kan hantera det ensamma.

Det är lätt att bära låtsas att principer som SOLID, TDD, etc är något som en individ bara kan plocka ner och genomföra genom svepande förändringar i ett dåligt kodat projekt, men i verkligheten kan det faktiskt vara självdödande när det gäller de underliggande målen för SOLID och liknande principer och teorier om programvaruarkitektur. Precis som den bästa mjukvaruimplementerade algoritmen görs effektivt värdelös om ingen person som behöver den faktiskt kan använda den relaterade programvaran, är den mest välarkitekterade programvaran värdelös när det gäller dessa arkitektoniska aspekter om teamet som arbetar med den inte längre kan göra det effektivt ( detta skär visserligen några andra relaterade vinklar i syfte med denna diskussion).

Ibland pekar detta på ett behov av personalbyte, men såvida du inte är i stånd att fatta relaterade beslut är det viktigt att komma ihåg att det inte är ditt val eller din position. Att driva på egen hand, särskilt om en annan tidslinje hade utvecklats och godkänts, kan till och med vara det värsta möjliga steget, och du kan skapa en värre röra för dig själv än bara den som är rätt i ditt ansikte, för andra människor hade kanske planer på hur man skulle hantera situationen och nu istället sprängde det bara. Poängen med de flesta moderna mjukvaruteknikprinciper är att sluta bara låtsas att koden är skriven i ett perfekt vakuum, så kom ihåg, det handlar verkligen om att vara realistisk om de involverade . Detta inkluderar resten av laget.

Jag tvivlar på att du kommer att göra några vinster på detta, det är väldigt svårt att motivera att skriva om något till ledningen utan att leverera ny funktionalitet, det är nya glänsande saker att spela med att ledningen bryr sig om, ju mer nytt användargränssnitt som är involverat desto bättre. Jag förvandlade precis en enda trådig tråkig dinosaurie till ett multitrådat mästerverk och ingen skit för det fanns inget nytt de kunde klicka på på skärmen

Coach The Veteran

Andra svar har gett goda råd om hantering av äldre kod och ledning. Jag vill fokusera på vad jag tycker är din kärnfråga: att hantera den ursprungliga utvecklaren. Så du ser inte öga mot öga på många saker. Om du vill att han ska sluta underminera dig måste du få honom med i ditt lag. Vilket innebär att du behöver honom för att se världen som du gör. Och sättet att göra det är att börja med att förstå hur hans värld ser ut, i detalj.

Läs äldre koden och försök destillera mönster och implicita regler som du inte håller med. Notera dessa, för det är här du vill komma på samma sida. Tänk sedan på varför du inte håller med dem. Fokusera inte på varför det äldre mönstret är dåligt . Fokusera på varför ditt ersättningsmönster är bättre , men erkänn också den grundläggande teorin för teknik: allt är en kompromiss . Även ditt "bättre" mönster har en svaghet under vissa förhållanden. Du måste kunna identifiera och förstå dessa fellägen för att framgångsrikt argumentera för att de är minst relevanta för de aktuella scenarierna. När du har gjort det här förberedelsearbetet är du redo för nästa steg.

Parprogrammering

Berätta för din kompis att du gick av med fel fot, du är ledsen för att vara en arrogant, nedlåtande röv och du vill bara ta reda på hur du kommer på samma sida. Välj lite kod som symboliserar de antimönster du identifierade ovan och titta på den gamla kontra din "förbättrade" version sida vid sida. Be utvecklaren att kritisera de två och ge honom gott om tid och utrymme att göra det. Leta efter möjligheter att komma överens med honom, snarare än att vara oense. Du försöker bygga broar vid denna tidpunkt. Oenigheten är redan underförstådd. När han har gjort sina observationer kan du ställa ledande frågor för att illustrera varför du tycker att din version är bättre. I synnerhet ta fram scenarier för exekvering av kod där din kod uppenbarligen är överlägsen. I allra bästa fall ha testfall till hands (enhet eller acceptans) som illustrerar överlägsenheten i din version, och be honom bara att granska dem.

Ditt mål är inte att fånga killen i en fälla, men att hjälpa honom att se världen ur ditt perspektiv. Och det fungerar bara om du först validerar hans perspektiv på någon nivå. I synnerhet måste du vara mycket känslig för historik . Många saker som vi betraktar som "dåliga" idag var vanliga eller accepterade eller till och med bra årtionden sedan, eftersom tekniken var annorlunda, kunskapen var annorlunda, hårdvaran var annorlunda. Försök att berätta för Grace Hopper att "GOTO anses vara skadligt." Hon svarade: "Ung man, jag skulle vilja se dig skriva ett monteringsprogram utan några JMP-instruktioner. Kom tillbaka när du är klar."

Det betyder att du kan och bör förstå systemets arkitektur i sammanhanget när det byggdes första gången . Även om det inte var avancerad teknik då, kan det ha byggts på relativt mogna mönster som senare ersattes. Du kommer långt genom att visa medvetenhet och respekt för denna utvecklingshistoria. Allt detta är det viktigaste du måste lära dig: "Koden är inte bra eller dålig . Den är bra eller dålig relativt något sammanhang . " Det är mycket möjligt att om du var närvarande när koden ursprungligen skrevs, kan du ha skrivit den på ett liknande sätt. För bara ett decennium sedan diskuterade jag med hela mitt team på ett stort Fortune 100-teknikföretag om dygden av enhetstester. Det är inget sätt jag skulle ha det samtalet idag. Många saker förändras med tiden.

Be om hjälp

Om din kompis är särskilt oupphörlig, välj bara ett fel för att fixa in en bit av koden som du inte har omformulerat. Be honom att kika med dig om det. Säg: "Jag har inte sammanhanget för att felsöka den här koden effektivt. Kan du visa mig din inställning till detta?" Låt honom vägleda dig med hans process. När han gör något som åberopar stamkunskap, låt honom pausa och säga: "Åh, vet någon annan det?" "Självklart inte." "Ok, för jag skulle inte ha gissat det bara genom att titta på koden. Kan vi ta en stund att dokumentera det?" Efter ett tag kommer handhållet att riva på hans nerver, och han kommer att se att bara för att det är lätt för honom att navigera i koden kan det vara komplicerat och frustrerande för någon annan att göra det. Om du verkligen vill köra poängen hem, få honom att kika med junior dev medan du tittar över allas axlar. Coach juniorutvecklaren så att du använder samma frågeställning-snarare än utmanande tillvägagångssätt som du.

Om du har tur blir han frustrerad och säger något som: "Ok, om du är så smart, hur skulle du göra det?" Säg sedan: "Tja, vi har en felrapport som visar att det finns ett fel någonstans i någon kod som jag har omformulerat. Låt oss ta en titt på det." Låt honom sedan navigera i din nya kod och fråga / utmana dig om den. Använd enhetstesterna som du har skrivit för att hjälpa till att isolera felet och låt junior dev köra en del av tiden för att illustrera att det inte bara handlar om honom eller dig, utan hela laget. om du har fokuserat på empati och kvalitet, snarare än omdöme och grovhet, så kommer du att hjälpa honom att se att du faktiskt har gjort värdefulla förbättringar, snarare än att bara skämta med systemet som han byggde under ett decennium. Istället för att insistera på att du är den alvetande arkitekten som kommer att ge godhet och ljus till all kod, börja om med en hälsosam dos ödmjukhet och låt din kod tala för sig själv. Om han är en rimlig kodare måste han så småningom erkänna att bättre kod är bättre kod som även han föredrar att arbeta med. Och om du inte kan få honom till den punkten kan det mycket mer ha att göra med din attityd än hans. Tänk på det och lycka till.

TL; DR: om du inte överdrev, kanske det inte finns något du kan göra för det projektet. Men du kan försöka kalla det ett nytt projekt och köra det separat.

Jag har varit i nästan exakt din situation mer än en gång. Jag kan inte säga att du har rätt uppenbarligen eftersom jag inte vet allt om ditt specifika projekt, men ibland är det verkligen svartvitt som du uttrycker det, trots vad andra säger.

För min första arbetsgivare på min karriär hade jag turen att ha stillestånd också. Jag fortsatte att se så många hemska misstag av ett par devs att jag bestämde mig för att hjälpa till. De vägrade, men jag personligen var en av de människor som var tvungna att hantera nedfallet av skräp när människor klagade så jag trampade på tårna ändå.

Jag gjorde en bättre version. Jag var i mer direktkontakt med slutanvändarna än killen vars tår jag trampade på, så jag fick även testa det. De älskade det och vissa bytte till det.

Vår egen kundtjänstchef (en datorkille som förstod de tekniska konsekvenserna) sa att han ville att den officiella versionen skulle ersättas med min, men killarna med senioritet gnällde åt det , min version tappades som en sten ... men ungefär ett år efter att jag bytte jobb fick CTO på det gamla stället mitt nummer från min gamla chef och CTO ringde personligen och frågade om jag skulle komma tillbaka under ett tempkontrakt för att stödja min version av det verktyget! Jag var intresserad, men han tyckte inte om det pris jag citerade (mycket mindre än vad jag vet att de spenderade på skräpversionen) och han ringde aldrig tillbaka igen.

Hos min nästa arbetsgivare fick jag välsignelsen att göra en "lite" version av en av deras produkter. På cirka 2 månader skapade jag en version som hade färre buggar, sprang mycket snabbare även på mindre hårdvara, var lättare att underhålla och uppdatera, hade bättre arkitekturdokumentation och till och med började bli funktionsrikare än originalversionen (och vissa funktioner de ville till och med överföras till den fullständiga versionen) ... tills någon sa "Hej, vi borde bara ersätta den fullständiga versionen med den här bättre." Då bam! Plötsligt blev "lite" versionen axlad. Jag sattes tillbaka på den fullständiga versionen, komplett med alla dess hemska kodluktar (det är en underdrift: det hela var mossa av evig stank), brist på dokumentation och buggar och sådant.

Hela version kraschade faktiskt vid start mycket, ibland krävde 10 försök eller mer innan den började ordentligt, och svaret på det var att inte ringa programvaran direkt, utan istället att göra ett startskript för det som bara försökte i en oändlig slinga för att starta det i flera minuter. Det spelade ingen roll för killen med mest senioritet och hans vän i ledningen.

Ibland finns det bara inget du kan göra.

Om din kamrat är verkligen så tät eller så envis som du föreslår och du överdriver inte, då kan du behöva bara överge idén att få hans stöd. I så fall måste du bara övertyga vem som kan fatta beslutet och lämna det där.

Om du inte kan övertyga din kollega eller chefen med beslutsrollen, är det en förlorad sak och du behöver bara gå av det projektet. Förhoppningsvis är arbetsgivaren tillräckligt stor för att du kan byta.

En annan väg, även om det fortfarande är något som ändrar projekt, är ...

Sälj din programvara som en ny produkt

Jag menar inte nödvändigtvis att starta ditt eget företag för att tävla mot din arbetsgivare. Det är ett alternativ, men vad jag menar är att sälja dem idén att din programvara kan betraktas som "Our App 2.0" eller kalla det en helt annan programvara.

Microsoft har både Internet Explorer och Edge. De har Notepad men de har också Wordpad och Word, var och en bättre än den före den.

Du kan sälja din programvara som konkurrent till din kamrats programvara även om det är samma företag som gör det. Då kan din kollega ha sin mjukvara precis som den är, och om ingen vill ha det kommer hans projekt att dö av sig själv.

Presentera det nya systemet

Ordna ett stort team \ teknisk teampresentation i det nya systemet. Demo felsökningsprocessen med det gamla systemet. Demo sedan för att hitta ett fel med det nya systemet. Använd helst faktiska exempelfrågor som ledningen vet är legitima, inte några små orkestrerade buggar.

Att se är att tro. Den ursprungliga utvecklaren kommer att ha svårt att försvara det gamla systemet när det nya systemet ses i handling.

Ge sedan statistik som visar hur många fel som hittats med det nya systemet över X-tid.

Slå inte på det tidigare systemet och hur illa det är. Sälj bara det nya systemet och hur bra det är utan arrogans, vilket är viktigt. Du vill få vänner att stödja det nya systemet, inte göra fiender som kan motstå det.

Visa tiden - kräva skälen.

Kör gammal kod och din och visa hur mycket tid du sparar.
Visa hur gammal kod skulle motsvara skräp när du flyttar till molnet. Visa att om det slutar fungera blir körtiden noll. Om det slutar fungera skulle det inte bara översättas till mer tid / arbetstid för att fixa det utan också skulle stoppa all "produktion".

Gör dem medvetna, så att de personligen kan bevisa det, att ett gammalt system med buggar är mycket mer vurnerbart att utnyttja.

Du måste i princip bevisa att systemet inte fungerar. Det är bara "igång". Och även en liten sten kommer att krossa den.

Problemet är att det du gör är att få den gamla rockstar-utvecklaren att se ut som om han utvecklat något hemskt. Så detta är en direkt kritik till honom. Med tanke på att du är en så skicklig arkitekt är det ganska konstigt att du inte hade stött på detta beteende tidigare men du bör vänja dig vid det. Jag är utexaminerad och jag stöter på detta beteende ofta. Lösningen på detta måste du själv hitta.

Om det blir nödvändigt för dig att "hjälpa" ledningen att veta "vem man ska tro", föreslå att de läser den här QA-tråden.

Men håll din CV uppdaterad - jag är säker på att en av orsakerna till min uppsägning var att skära samman kompileringstiden och den körbara storleken i hälften genom ett tillvägagångssätt som en "mer erfaren" kollega hade sagt att ledningen var omöjlig när jag rekommenderade det.

Ett av svaren slog redan nära vad jag ville säga, men jag tycker att det är värt att kondensera, så jag håller det kort.

Chefer, särskilt icke-tekniska chefer, som siffror. De gillar diagram. De behöver hårda siffror som kan motivera deras beslut. Det här är allt du verkligen behöver för att visa dem.

Sätt ihop ett par bilder som visar (om möjligt):

  Ny vs gammal distributionstid Frekvens av buggar med timeTime att fixa buggar 

Saker av den här typen. Få ett par bra statistik tillsammans, håll den kort och snygg, visa den för ledningen och du kommer garanterat att ha deras uppmärksamhet om dina bidrag är så genomslagskraftiga som du hävdar. Det här är verkligen allt du behöver göra för att övertyga ledningen. Resten av svaren handlar främst om kontorpolitik, vilket jag rekommenderar att du undviker i fall där du kan visa din poäng med solida siffror / grafik. Oroa dig inte för den andra utvecklaren, när du väl har övertygat ledningen åligger det honom att komma över sig själv eller hitta ett annat jobb.

Ledsen för ett så kortfattat svar, men här är en enkel och viktig sak som jag lärde mig av min tidigare erfarenhet att jag är rädd att du saknar:

Konsistens är viktigt