Kom ihåg att kodning inte finns i ett vakuum. Även kod som är mindre än ideal kan lösa verkliga affärs- eller humanitära problem.

Kvalitet är inte ett allt-eller-ingenting-förslag. Det finns verkligen situationer där ett team är så yngre att införandet av komplexitet kan döda produktivitet och moral och misslyckas med att leverera ens de grundläggande målen för hela projektet.

Jag antar att du själv inte startade din karriär som gör TDD, hån, programmering till gränssnitt, beroendeinjektion, komposition över arv, distribuerad versionskontroll och liknande.

Försök kompromissa. Gör en plan med cheferna för att införa moderna programvaruutvecklingsmetoder över tid. Erbjud dig att lära resten av teamet i dessa principer med hjälp av en-mot-en-mentorskap, lunch och lärande eller själv -riktad utbildning.

Se om det finns trevliga funktioner som teamet kan använda för att experimentera med tekniker som är nyare för dem, där du skulle övervaka kodkvalitet, recensioner, godkända tester och vad som helst annars hittar du nödvändigt.

Det handlar om att hitta en balans mellan omedelbar produktivitet och långsiktiga metoder för hållbar utveckling.

Det tar naturligtvis tid och du kommer måste avgöra om den tiden är värt din personliga investering. Om cheferna inte är villiga att kompromissa, kommer troligen beslutet att fattas åt dig.

Denna linje förstörde mitt förtroende för ditt företags ledare:

Ingen mer testdriven utveckling och inga fler enhetstester.

Det är så dåligt beslut kan jag inte tänka mig att arbeta någonstans som beter sig eller tror på det. Du kommer att slösa bort 10 till 100 timmar med att fixa fel, eftersom de vill spara 1 timme genom att inte använda testdriven utveckling eller enhetstester.

Det är dålig programmering, dålig affär och förråder brist på förståelse för system tänkande. Sådana människor kan inte lita på. De är oförmögna att på ett tillförlitligt sätt fatta bra beslut inom något område av verksamheten.

Utan systemtänkande kommer ledare på sikt att skada dig.

Gå ut nu.

Jag har kämpat den här striden mer än två gånger.

Här är vad du kommer att inse någon gång: Ingen chef vill erkänna (och förmodligen till och med sig själva) att de producerar sopor. De kommer antingen att möta smärtan och göra de nödvändiga förändringarna för att producera en bra produkt, eller så kommer de att "motivera" beslutet med en kombination av elände om en budgetkris och irrationella rationaliseringar som du har beskrivit ovan.

Organisationen har talat, och du kan inte bekämpa den här AND leverera en bra produkt samtidigt.

Du kan antingen göra fred med att sätta ditt namn på något du vet att inte är upp till dina normer, eller om du hittar någonstans att dina talanger och standarder kommer att gynna.

Det är inte din produkt, i princip måste du anpassa dig eller gå vidare.

Som frilansare borde du ha upplevt det tidigare. Du måste arbeta inom vad de som betalar dig tillåter dig. Det är uppenbart att de inte gillar din leadstil och du är störande för deras team, så efter att ha granskat deras alternativ (utan dig) är det vad de kom på.

Se till att du får betalt och försök att lämna på bra villkor när du är redo, men bli inte upprörd över en produkt du inte äger.

Bara ett förslag, men programmeringskunskaper är inte allt när du arbetar med ett team i något typ av huvudroll. Du kanske gör det mycket bättre när du letar efter soloprojekt som verkligen kan få dina färdigheter att lysa ut. Det är en av anledningarna till att jag ofta avvisar jobb som involverar ett okänt team som inte kunde göra det själva (om de var kompetenta och effektiva skulle de inte behöva mig). Jag föredrar att börja från grunden antingen solo eller med mitt eget team. Mindre huvudvärk och mer trivsel (mer pengar också vanligtvis).

Lägg dina pengar där din mun är. Lämna.

Avgå från positionen och informera hela ledningskedjan om att du inte kan fylla i det du anställdes för, och som sådan, som frilansare, snarare säga upp kontraktet än att stödja en substandard utvecklingsinsats . Informera dem om att detta är ett kontraktsbrott (förutsatt att du anställdes för att faktiskt fatta dessa beslut) och som sådan ser du det inte motiverat att slösa bort din tid - och deras pengar - på din lön.

Där är inte mycket du kan göra. Om du inte har dolda motiv (behöver pengar för andra projekt) är det det mest uppriktiga sättet att hantera detta, med tanke på att du personligen kämpar för hur projektet går.

Alternativt kan du kontakta högre upp och försöka hitta ett sätt att få saker att fungera på en acceptabel nivå. Det är möjligt, thugh, de arbetar med människor som hellre skulle vända hamburgare på McDonalds - sett i ganska många större företag. Jag anställdes en gång för att lära VB-utvecklare C #. En läroplan för en månad kondenseras till tre dagar ("vi kan inte få dem att inte fungera på en månad, och alla är erfarna utvecklare"). De erfarna utvecklarna visste inte skillnaden mellan en array och en hashtable / ordbok på grundläggande nivå, så hela tiden var bortkastad. Det är nivån i vissa företag.

Du kan inte bekämpa den. Fisken börjar stinka från huvudet - vilket är förvaltningen. De betalar för det över tiden. Men det är inte ditt jobb att ändra det. Om du inte tål det, gå.

Jag skulle fokusera på olika saker. Eftersom:

Ingen mer testdriven utveckling och inga fler enhetstester.

Det här är sugt men det är förståeligt. Det är ett enormt paradigmskifte och det passar bäst ett helt nytt projekt, inte en fortsättning på ett gammalt.

Inga sådana högt krävande kodrecensioner.

Det är också förståeligt. IMHO-nivån för krävande bör ökas gradvis för att låta människor lära sig nya färdigheter.

Någon kopieringspasta från den gamla versionen av applikationen för att gå snabbt för andra utvecklare.

Det är förståeligt och kan vara OK - om de gamla styckena röra skiljs snyggt från resten av projektet.

Nu har du listat de saker de har tappat, men listan kan inte bedömas utan att du vet hur mycket av dina rekommendationer som fanns kvar. Om dessa tre var hörnstenarna i din metodik finns det inget kvar av din design och det är dåligt. Om de bara var 3 av 15, är det mesta fortfarande på plats och att släppa dessa 3 är verkligen vad det står på etiketten: dämpar chocken för återstående programmerare.

Men den andra delen är mest alarmerande för mig:

Vi hade ett möte (utan mig så), och vi släppte några metoder som du rekommenderade.

De bad dig att utforma något och sedan modifierade de designen utan att rådfråga dig. Det är den röda flaggan. Antingen för dem eller för dig - för det kan vara du som bara vägrar att höra deras argument till den punkt de måste utfärda en direkt order.

Om du uppskattar att de har tappat större delen av din plan kan det betyda att de inte förstår någonting. De vill att deras kod ska förbättras, de kan betala din lön, men de betalar inte den verkliga kostnaden: ansträngningen. Det är som en kille som köper proteintillskott med förgäves hopp om att en produkt magiskt ger dem muskler utan träning. Proteintillskott fungerar inte på det här sättet och du är inte heller en magisk produkt som kan fixa deras process utan att ändra den. Det är skrämmande hur många människor tycker att magiska kulor är riktiga.

Å andra sidan strävar kommersiell mjukvaruproduktion inte efter absolut perfektion, det är bara tillräckligt strid (vilket betyder tid, vilket i sin tur betyder pengar) investerat i perfektion idag för att spara ännu mer ansträngning (läs: tid, läs: pengar) på lång sikt. Varje fix kostar pengar och det är bara motiverat om det går ännu mer att lämna felet. Det du verkligen behöver vara bra på är kompromiss. Inte alla är klara för jobbet (det är verkligen inte för mycket perfektionist som inte hjälper), det enda sättet att ta reda på är att prova det.

Det är upp till dig att bestämma om mängden designfrihet vänster räcker. Om du känner att de har anställt dig för att göra ett jobb och nu säger de att du inte kan göra jobbet, kan det vara bara att slösa bort all tid att stanna där.

Du kan alltid behandla jobbet som en lektion. Distansera dig, observera och lär dig. Även om du är tekniskt perfekt behöver du fortfarande "arbeta med andra människor". Heck, att arbeta med människor som inte är så bra som du kräver ännu mer av den färdigheten.

Jag skulle inte koncentrera mig för mycket om de beslut som togs. Den viktiga informationen här är: de tog på sig att ha ett möte utan dig om saker som var ditt ansvar. Det visar en förlust av förtroende för dig .

Du måste förstå varifrån det kom i första hand. Du ser tekniskt adekvat ut med tanke på vad du frågade: du övertygade dem som sådana. men de anställde dig inte för du är tekniskt bra, de anställde dig för att åtgärda ett problem de hade och trodde att du kunde göra det.

Jag kan se flera problem som kan hända med denna dissonans (det faktum att du tror att de anlitade dig för en sak, jämfört med den verkliga anledningen):

1. Brist på mål:

   • Sa de dig vad de förväntade sig av du?
   • Frågade du vad de ville ha?
   • Saknade du något de sa till dig?
   • Du kanske hörde: "Vi vill ha kvalitetsprogramvara!" när de menade "Vi vill ha en programvara som människor använder!".

2. brist på öppenhet: Du kommer till det här nya jobbet och tillämpar alla de bästa kända metoderna i dina fält.

   • Hur kommunicerade du om det?
   • Gick du för fort?
   • Var alla medvetna om konsekvenserna eftersom det alltid finns en kompromiss?
   • Förklarade du att inlärningskurvan kommer att skada produktiviteten?

3. Stöd nedan: Din metod påverkade ditt teams liv, de behöver för att vara övertygad om att de går i rätt riktning.

Jag kan bara spekulera vid den här punkten men jag kan se varför, inom några månader, utvecklarna freaked out eftersom de inte ser mervärdet (ändå) av ändringarna och dina chefer freaked eftersom funktionerna inte kommer lika snabbt som de trodde att du skulle leverera och utvecklarna kommer tillbaka på dem, olyckliga.

Du måste lära dig av den här upplevelsen nästa gång eftersom det är ganska avancerat i ditt fall.

Men om det finns något att spara, är det genom tillit och tålamod. Om något,

• Gå vidare med flödet genom att erkänna problemen de tog upp.
• Acceptera de flesta av deras ändringar och lägg till dina mest värdefulla poäng (endast under förutsättning att du ser en framtid här)
• Gör ett schema för att återinföra de bästa metoderna långsamt men säkert och förklara vilka problem dessa metoder fixar (inget behov av fallskärmar i bilar, men bilbälte kan hjälpa;)

Övertyga människor att vara på din sida, oavsett kostnad, för om du inte kan göra det, din kamp är förlorad.

Jag är inte säker på de exakta detaljerna i din situation, men att ha teknisk expertis och att leda ett team att göra saker på ett specifikt sätt är två separata saker tror jag. Boken "Extreme Ownership" går djupt in i lagdynamiken, kanske skulle det vara till hjälp.