20 grunde til, at programmelprojekter mislykkes
hvert programmelprojekt begynder med store drømme og store visioner. Et eller andet sted i et alternativt univers er der et projekt, der opfylder enhver drøm, men alt for ofte snuble programmelprojekter i vores univers mod målstregen og undertiden krydser den.
selvfølgelig er programmelprojektfejl ikke en binær ting. Du kan ende med kode, der kører godt, men ingen bruger. Eller du kan ende med kode, der ikke engang kompilerer. Nogle gange kan du redde noget nyttigt fra Det flammende vrag, og nogle gange er det bedst at løbe væk, før det eksploderer.
når det ulmende rod afkøles, begynder obduktionerne, da folk vil vide, hvad der gik galt. Her er de mest almindelige syndere.
for få teammedlemmer
at prøve at gøre for meget med for få programmører er et almindeligt problem. Udviklere kan kun male så meget kode ud, før de brænder ud. Jeg arbejdede engang på et team, hvor lederen troede, at den rigtige måde at presse mere arbejde fra agile teams er at planlægge hver “sprint”, så det begyndte umiddelbart efter den forrige. Ingen tankevækkende pauser for at finde ud af, hvad der fungerede, og hvad der ikke var. Sprint 42 sluttede onsdag kl 1:59pm og Sprint 43 begyndte onsdag kl 2:00pm. Retrospektive analysemøder blev planlagt efter den næste sprint allerede startet. Nogle kloge fyr foreslog, at de blev omdøbt til “marathons” og snart fandt et andet job.
det er selvfølgelig svært at vide, hvor mange programmører der er nok. Nogle gange kommer vejspærringer og problemer i vejen. Det er måske ikke lederens skyld, at jobbet fordobles i størrelse, men hvis du ikke har nok mennesker på jobbet, er dit projekt sandsynligvis dømt.
for mange teammedlemmer
hvis for få programmører kan være dårlige, kan for mange potentielt være værre, da netværkseffekter kan dømme et programprojekt. Flere mennesker betyder mere koordinering, og det betyder flere møder, der tager tid væk fra at skrive kode. Men hvis du ikke holder nok møder, vil du snart opdage, at Team A ‘S API ikke interface Team B’ s microservices.
det ville være rart, hvis vi bare kunne kaste penge på et problem ved at overbelaste et projekt, men det kan du ikke.
for meget kommunikation
skriveprogram er en ensom kunst. Mennesker kan arbejde sammen, men kun i begrænsede anfald. Mange udviklere hader møder, fordi de har brug for at skifte deres mentale gear fra den dybe fordybende logiske tanke til den mere åbne, social tilstand. Det tager tid. Nogle teamledere forsøger at bekæmpe fiasko ved at holde flere møder for at holde alle synkroniserede. Det er en ædel indsats, men du kan høre gearene slibning. Holdet skal dele nok information til at forblive synkroniseret, men mere spilder bare hjernecykler.
grundlæggende funktionsændringer
i teorien kan udviklere betragte sig som agile. Derfor omfavner de ordet. Men nogle gange kan agility kaste alle ud af balance. Det hele afhænger af, om skiftet kræver grundlæggende ændringer i den underliggende ramme. Det er nemt at være adræt, når du flytter en knap rundt eller ændrer en farve. Men når det involverer omarbejdning af databaseskemaet eller mucking rundt med sharding og replikation, er der ingen nem måde at yndefuldt dreje på.
Vælg den forkerte teknologi til jobbet
selvom du planlægger omhyggeligt og udarbejder den korrekte liste over funktioner, kan ting mislykkes, hvis du bruger den forkerte teknologi. Databaser, for eksempel, er designet til at være generelle og fleksible, men har arkitektoniske begrænsninger. Skub dem til at levere noget, de ikke er designet til at gøre, og de vil bremse til en virtuel stop, når de bliver bedt om at skalere. Eller du kan starte med en Noskl database, fordi de lyder cool kun at opdage senere, at du virkelig har brug for syre-grade transaktioner for at holde tingene konsekvent og databasen ikke tilbyde dem. Ups.
dårlig prioritering
gode planlæggere udarbejder en liste over funktioner og prioriterer dem. Men nogle gange stemmer prioriteter ikke overens med virkeligheden ved at implementere dem. I værste fald er de vigtigste funktioner de sværeste at skabe.
Hvad skal dine udviklere gøre? Hvis de koncentrerer sig om den vigtigste funktion, vil de ikke gøre fremskridt og kan ende med at levere ingen af funktionaliteten. Men hvis de begynder at slå de lette af, kan de ende med noget, der er værdiløst.
god planlægning kræver mere end en tjekliste. Arkitektonisk vision skal tage hensyn til behovene og omkostningerne ved at levere dem.
markedsvinduet lukker
nogle gange er det ikke programmørens skyld. Et af mine projekter var at gøre en bedst sælgende referencebog til en app. Bogen solgte som hotcakes i årene før internettet. Planen var at udnytte denne efterspørgsel og lave en interaktiv version, der ville lade folk sortere og søge gennem dataene. Programmeringsteamet leverede programmer, der inkluderede alt i bogen, men var hurtigere, smukkere og meget lettere end selve bogen. Men ingen ville have det mere. Der var nok andre kilder, og ingen havde brug for en anden app, der gjorde meget det samme som nyhedssider gør overalt.
nogle gange virker en ide stor, men markedet er gået videre.
dårlige arkitektoniske beslutninger
på et projekt fik jeg jobbet med at ændre et nummer i en række i databasen. Da brugeren var færdig med at registrere, skulle jeg tilføje Brugerens id-nummer til den seneste ordre. Lyder simpelt, ikke? Men systemet blev bygget på en mikroservices arkitektur, og jeg kunne ikke løse dette ved at skrive en linje kode, der ville fortælle databasen at opdatere den kolonne. Niks. Den arkitektoniske plan var at tilføje et nyt microservice-opkald til den eksisterende stak, og selv dette var svært, fordi mit første microservice-opkald var nødvendigt for at udløse et andet microservice-opkald og så videre.
til sidst fortalte den arkitektoniske sus, der skabte dette netværk af mikroservices, mig, at det hele var meget enkelt og skitserede en slangevej gennem fem lag af arkitekturen. Mit job var at tilføje fem nye API-opkald til fem forskellige mikroservices, hvilket også betød at tilføje fem sæt automatiserede tests for hvert lag. Og hver API blev udviklet af et andet team gennem årene, kræver mig at forstå og efterligne fem forskellige stilarter af kodning. Alt for at ændre et nummer.
arkitektoniske beslutninger kan vare hele livet — især hvis dit ego er grundigt investeret i dem, og du ikke kan ændre dem. Projektledere skal være klar til at lægge mærke til, når den vigtigste arkitektoniske plan ikke fungerer, så store beslutninger kan træffes.
politiske konflikter
at beskylde politiske faktorer for en teknisk fiasko kan virke væsenligt, men det er i stigende grad sandt. Efterhånden som projekter bliver større og spænder over flere organisationer, bør det ikke være en overraskelse, at fraktioner vises og grupperer jockey for kontrol, ressourcer og i sidste ende magt.
politiske fraktioner adskiller sig fra reelle tekniske forskelle. Der er ofte tekniske standarder eller kodebaser, der gør meget det samme på forskellige måder. Tag JSON og JSON. Nu hvor jeg har skrevet det, kan jeg føle fansen af enten at skynde sig for at forklare, hvorfor de ikke er de samme, og deres yndlingsvalg er det rigtige. Men når en del af et hold elsker et valg, og en anden holder den konkurrerende fraktion i højeste henseende, godt, friktion vil rive dem fra hinanden.
dette er blevet endnu mere almindeligt, da arkitekter opdeler applikationer i flere, mindre tjenester og API ‘ er. Forskellige grupper vil ende med at kontrollere disse, og de kommer ikke altid sammen. Hvis gruppe A kan lide JSON og gruppe B klamrer sig til JML, godt, dit team bliver enten nødt til at implementere begge eller få en af dem til at ændre sig. Alle tre er en smerte for ethvert hold, der skal arbejde med både gruppe A og gruppe B.
væddemål på teknologi, der ikke er klar til produktion
programmører elsker de nyeste værktøjer og rammer. De ønsker at tro, at den nye tilgang vil feje alt det cruft, der moser ned den forrige generation.
men ofte er den næste generation ikke klar til produktionsbrug. De nye funktioner kan virke perfekte, men der er ofte huller, der ikke umiddelbart er indlysende. Nogle gange understøtter koden kun et par filtyper eller grænseflader med kun få databaser. De andre kommer snart, de forsikrer dig, men dit projekt skal sendes denne måned, og “snart” kan betyde seks eller flere måneder, før de funktioner, du har brug for, er komplette.
væddemål på teknologi, der snart bliver forældet
efter min erfaring er de gamle ting normalt mere pålidelige og kamptestede, men det betyder ikke, at gammel teknologi er perfekt. Funktioner kan mangle, der er afgørende for dit program projekt, når det går live. Værre, at satse på gammel teknologi kan få dig til at gå glip af fremtidige muligheder baseret på ændringer ned ad linjen. Nye ideer, protokoller og filformater vises, og de kan gå uimplementeret. Og hvis nogen fra et konkurrerende hold insisterer på, at du støtter en ny protokol, vil den gamle teknologi skade.
urealistiske deadlines
Deadlines er vanskelige. Mange projekter skal gøre det til markedet ved en bestemt sæson eller begivenhed. Men når deadlines først skrives ned, er dine udviklere ikke begyndt at opdage vejspærringer og forhindringer i vejen. Så hvis projektet glider og begivenheden passerer uden programmet bliver lanceret, hele projektet ses som en fiasko, selvom koden er lige ved at køre problemfrit. Deadlines hjælper alle med at fokusere og trække sammen, men de skaber også forventninger, der kan være urealistiske.
uforudset konkurrence
en god produktchef undersøger konkurrencen inden dykning, men ingen kan forudsige, hvilken konkurrence der kan vises ud af ingenting. Hvis nye konkurrenter introducerer nye funktioner, som du skal duplikere, godt, se afsnittene om funktionsændringer og prioriterede uoverensstemmelser, over.
Rushing processen
mange programmelprojekter starter som visionen for en person eller et team, der ønsker at ordne noget. De kommer med en sætning som “Snapchat for Y” eller “Uber for Y” og forventer derefter, at produktteamet er lige så lydhør som Snapchat eller Uber. Problemet er, at det ofte er ti gange så meget arbejde at finde ud af projektets omfang, skitsere datastrømmene og forestille sig brugergrænsefladen som at skrive koden. Men imagineers ønsker at gå fra ide til kode med det samme.
trådrammer, databaseskema og brugerhistorier er ikke kun håndvinkende, men en væsentlig del af jobbet. Men de fleste mennesker vil tro på, at et programprojekt bare skriver kode for at implementere en ide.
falsk tro på programmernes magt
drømmere har ofte urealistiske overbevisninger om programmernes magt til at ændre verden. Mange forestillede sig, at sociale medier ville forene os, men på en eller anden måde er det bare udsatte fejllinjer, der altid var indlysende. Programmelprojekter begynder ofte med diasdæk, der lover at revolutionere et hjørne af verden. Når shoving bits i en database ikke forvandle nogen, godt, folk bliver vred, keder sig, forvirret eller værre. De siger, at programmet er brudt, fordi det ikke leverer den magiske transformation, som alle forventede.
mange programmelprojekter kan kompilere, videregive kvalitetssikring, sende og endda få anstændige anmeldelser, men i sidste ende undlader at nå nogen af løfterne på diasdækket, fordi disse forandringsløfter er umulige.
onde underleverandører
vi elsker de leverandører, der producerer biblioteker og værktøjer, der gør det muligt for os at skabe magi med blot et par linjer kode. Lejlighedsvis får de vind af deres magt og bruger den til at ødelægge et projekt. Budgetarket for version 1.0 var så godt, at ledelsen ikke tøvede med at godkende version 2.0. Derefter beslutter sælgeren at presse os ved at tredoble eller kvintuplere prisen.
denne effekt kan mærkes, selv når sælgerne ikke gør det med vilje. Gratis niveauer kan få et projekt til at se meget billigt ud. Så når efterspørgslen stiger, og den anden version udvider efterspørgslen, sparker de reelle priser ind.
Havændring
i et år med pandemier og protester har intet ændret sig hurtigere end tidsånden. Har projektet gjort stærk beskyttelse af privatlivets fred til en central funktion? Whoop. Pandemien har gjort alle interesserede i kontaktsporing. Har nogen lyst til at fokusere på forretningsrejser? Whoop. Hotelbranchen er kollapset. Større programmelprojekter, der kan tage et år eller længere, risikerer at blive forstærket af katastrofale begivenheder. Hvad der syntes som en vidunderlig ide i starten, kan virke håbløst tabt og afbrudt, når det er tid til at gå live.
tekniske skift
det er ikke kun ændringer i verden som helhed. Tidevandsændringer i tech-samfundet kan have den samme effekt. Noskl var engang en genial ide, der ville befri os fra relationelt skema. Så indså nogen filerne oppustet, fordi hver post havde et lokalt skema. Et godt agilt udviklingsteam kan skifte, når teknologiske havændringer skifter ledelsens og kundernes holdninger. Men selv de mest smidige hold kan ikke håndtere store skift, der suger al luften ud af deres arkitektoniske planer. Systemet blev bygget under forudsætning af, at det var en god ide og pludselig er snavs. Nogle gange er det bedst at blæse det op og stjerne igen.
for mange tilføjelser
nogle programmelprojekter starter godt og sendes endda med succes. Derefter tilføjer nogen en ekstra funktion eller tre, podning af ny kode på den eksisterende version på en måde, som koden fortsætter med at halte sammen. Heroiske udviklere kan trække dette ud flere gange, især hvis den oprindelige arkitekt planlagde godt. Men på et tidspunkt smuldrer fundamentet. Måske kan databasen ikke håndtere belastningen. Måske er der for mange sammenføjninger, der er nødvendige for at tilfredsstille de forskellige forespørgsler. Godt program kan blive for fedt, nogle gange takket være små forbedringer, der skubbede det over kanten.
flytning af målindlæg
de oprindelige planer krævede en database, der sporer kundeudgifter for at hjælpe med marketingplaner. Derefter tilføjede et geni en funktion, der bruger kunstig intelligens til at korrelere udgifterne med vejrudsigten. Eller en anden ønskede, at programmet automatisk skulle byde på søgemaskineannoncer. Ændring af destinationen kan upend et projekt.
det er sjældent, at ændringerne ødelægger tingene alene. Men nye mål kan afsløre svagheder og udløse fejltilstande. Måske er holdet nu for lille til at gennemføre projektet med succes. Måske er de tekniske fundamenter vildt ineffektive for den nye tilgang. Det er svært for alle at forudse de fretful combinatorics, når beslutningen er truffet for at ændre målene.