20 anledningar till att mjukvaruprojekt misslyckas
varje mjukvaruprojekt börjar med stora drömmar och stora visioner. Någonstans i ett alternativt universum finns det ett projekt som uppfyller varje dröm men alltför ofta mjukvaruprojekt i vårt universum snubblar mot mållinjen och ibland korsar den.
naturligtvis är programvaruprojektfel per definition inte en binär sak. Du kan sluta med kod som går bra men ingen använder. Eller så kan du sluta med kod som inte ens kompilerar. Ibland kan du rädda något användbart från det flammande vraket och ibland är det bäst att springa iväg innan det exploderar.
när den smolande röran svalnar börjar obduktionerna, eftersom folk vill veta vad som gick fel. Här är de vanligaste synderna.
för få teammedlemmar
att försöka göra för mycket med för få programmerare är ett vanligt problem. Utvecklare kan bara slipa ut så mycket kod innan de brinner ut. Jag arbetade en gång i ett team där chefen tyckte att det rätta sättet att pressa mer arbete från agila team är att schemalägga varje ”sprint” så det började omedelbart efter det föregående. Inga tankeväckande pauser för att ta reda på vad som fungerade och vad som inte var. Sprint 42 slutade onsdag klockan 1:59 och Sprint 43 började onsdagen klockan 2:00. Retrospektiva analysmöten planerades efter att nästa sprint redan startat. Någon smart kille föreslog att de döptes om till” maraton ” och hittade snart ett annat jobb.
naturligtvis är det svårt att veta hur många programmerare som räcker. Ibland kommer vägspärrar och problem i vägen. Det kanske inte är chefens fel att jobbet fördubblas i storlek men om du inte har tillräckligt med människor på jobbet är ditt projekt sannolikt dömt.
för många teammedlemmar
om för få programmerare kan vara dåliga kan för många potentiellt vara värre, eftersom nätverkseffekter kan döma ett mjukvaruprojekt. Fler människor innebär mer samordning och det innebär fler möten, tar tid från att skriva kod. Men om du inte håller tillräckligt med möten kommer du snart att upptäcka att Team A: s API inte gränssnitt Team B: s mikrotjänster.
det skulle vara trevligt om vi bara kunde kasta pengar på ett problem genom att överbelasta ett projekt, men du kan inte.
för mycket kommunikation
skrivprogramvara är en ensam konst. Människor kan arbeta tillsammans men bara i begränsade anfall. Många utvecklare hatar möten eftersom de behöver flytta sina mentala växlar från den djupa fördjupande logiska tanken till det mer öppna, sociala läget. Det tar tid. Vissa lagledare försöker bekämpa misslyckande genom att hålla fler möten för att hålla alla synkroniserade. Det är en ädel ansträngning men du kan höra kugghjulen slipning. Teamet behöver dela tillräckligt med information för att hålla synkroniserad men mer slösar bara hjärncykler.
grundläggande funktionsförändringar
i teorin vill Utvecklare betrakta sig smidiga. Det är därför de omfamnar ordet. Men ibland kan smidighet kasta alla ur balans. Det beror helt på om skiftet kräver grundläggande förändringar i det underliggande ramverket. Det är lätt att vara smidig när du flyttar en knapp runt eller ändrar en färg. Men när det handlar om att omarbeta databasschemat eller mucking runt med sharding och replikering, finns det inget enkelt sätt att graciöst svänga.
plocka fel teknik för jobbet
även om du planerar noggrant och gör rätt lista över funktioner kan saker misslyckas om du använder fel teknik. Databaser, till exempel, är utformade för att vara allmänna och flexibla, men har arkitektoniska begränsningar. Tryck på dem för att leverera något de inte är avsedda att göra, och de kommer att sakta till ett virtuellt stopp när de blir ombedda att skala. Eller du kan börja med en NoSQL-databas eftersom de låter coola bara för att upptäcka senare att du verkligen behöver SYRAKVALITETSTRANSAKTIONER för att hålla sakerna konsekventa och databasen erbjuder dem inte. Oj.
Dålig prioritering
bra planerare utarbetar en lista över funktioner och prioriterar dem. Men ibland stämmer inte prioriteringarna med verkligheten att genomföra dem. I värsta fall är de viktigaste funktionerna svårast att skapa.
Vad är dina utvecklare att göra? Om de koncentrerar sig på den viktigaste funktionen kommer de inte att göra några framsteg och kan sluta leverera ingen av funktionaliteten. Men om de börjar slå av de enkla, kan de sluta med något som är värdelöst.
bra planering kräver mer än en checklista. Arkitektonisk vision måste ta hänsyn till behoven och kostnaden för att leverera dem.
marknadsfönstret stängs
ibland är det inte programmerarens fel. Ett av mina projekt var att göra en bästsäljande referensbok till en app. Boken såldes som hotcakes under åren före internet. Planen var att utnyttja den efterfrågan och göra en interaktiv version som skulle låta folk sortera och söka igenom data. Programmeringsteamet levererade programvara som inkluderade allt i boken men var snabbare, vackrare och mycket lättare än själva boken. Men ingen ville ha det längre. Det fanns tillräckligt med andra källor och ingen behövde en annan app som gjorde ungefär samma sak som nyhetssajter gör överallt.
ibland verkar en ide bra, men marknaden har gått vidare.
dåliga arkitektoniska beslut
på ett projekt fick jag jobbet att ändra ett nummer i en rad i databasen. När användaren slutade registrera, skulle jag lägga till användarens id-nummer till den senaste beställningen. Låter enkelt, eller hur? Men systemet byggdes på en mikroservicearkitektur och jag kunde inte lösa detta genom att skriva en rad kod som skulle berätta för databasen att uppdatera den kolumnen. Nepp. Den arkitektoniska planen var att lägga till ett nytt mikroservicesamtal till den befintliga stacken och även det var svårt eftersom mitt första mikroservicesamtal behövde utlösa ett annat mikroservicesamtal och så vidare.
i slutändan berättade den arkitektoniska whiz som skapade detta nätverk av mikrotjänster att det var väldigt enkelt och skisserade en serpentinväg genom fem lager av arkitekturen. Mitt jobb var att lägga till fem nya API-samtal till fem olika mikrotjänster, vilket också innebar att lägga till fem uppsättningar automatiserade tester för varje lager. Och varje API har utvecklats av ett annat team genom åren, vilket kräver att jag förstår och efterliknar fem olika stilar av kodning. Allt för att ändra ett nummer.
arkitektoniska beslut kan vara en livstid-speciellt om ditt ego är grundligt investerat i dem och du inte kan ändra dem. Projektledare måste vara redo att märka när huvudarkitekturplanen inte fungerar så stora beslut kan fattas.
politiska konflikter
skyller politiska faktorer för ett tekniskt misslyckande kan tyckas weaselly, men det är alltmer sant. När projekt blir större och spänner över flera organisationer, borde det inte vara en överraskning att fraktioner dyker upp och grupperar jockey för kontroll, resurser och slutligen makt.
politiska fraktioner skiljer sig från verkliga tekniska skillnader. Det finns ofta tekniska standarder eller kodbaser som gör ungefär samma sak på olika sätt. Ta XML och JSON. Nu när jag har skrivit det kan jag känna fansen av att antingen rusa för att förklara varför de inte är desamma och deras favoritval är den rätta. Men när en del av ett lag älskar ett val och en annan håller den konkurrerande fraktionen i högsta avseende, ja, friktion kommer att riva dem ifrån varandra.
detta har blivit ännu vanligare eftersom arkitekter delar upp applikationer i flera, mindre tjänster och API: er. Olika grupper kommer att sluta kontrollera dessa och de kommer inte alltid att komma överens. Om Grupp A gillar JSON och Grupp B klamrar sig fast vid XML, kommer ditt team antingen att behöva implementera båda eller få en av dem att förändras. Alla tre är en smärta för alla lag som måste arbeta med både Grupp A och Grupp B.
spel på teknik som inte är redo för produktion
programmerare älskar de senaste verktygen och ramarna. De vill tro att det nya tillvägagångssättet kommer att sopa bort all den cruft som myrar ner den tidigare generationen.
men ofta är nästa generation inte redo för produktionsanvändning. De nya funktionerna kan verka perfekta, men det finns ofta luckor som inte är omedelbart uppenbara. Ibland stöder koden bara några filtyper eller gränssnitt med bara några databaser. De andra kommer snart, de försäkrar dig, men ditt projekt måste skickas den här månaden och ”snart” kan betyda sex eller flera månader innan de funktioner du behöver är färdiga.
vadslagning på teknik som snart är föråldrad
enligt min erfarenhet är de gamla grejerna vanligtvis mer tillförlitliga och slagtestade, men det betyder inte att gammal teknik är perfekt. Funktioner kan saknas som är avgörande för ditt mjukvaruprojekt när det går live. Värre, att satsa på gammal teknik kan få dig att missa framtida möjligheter baserat på förändringar längs linjen. Nya ideer, protokoll och filformat visas och de kan inte implementeras. Och om någon från ett konkurrerande lag insisterar på att du stöder något nytt protokoll kommer den gamla tekniken att skada.
orealistiska tidsfrister
tidsfrister är knepiga. Många projekt måste göra det till marknaden av en viss säsong eller händelse. Men när tidsfristerna först skrivs ner, har dina utvecklare inte börjat upptäcka vägspärrar och hinder i deras väg. Sedan om projektet glider och händelsen passerar utan programvaran lanseras, hela projektet ses som ett misslyckande även om koden är på väg att löpa smidigt. Deadlines hjälper alla att fokusera och dra ihop, men de skapar också förväntningar som kan vara orealistiska.
oförutsedd tävling
en bra produktchef undersöker tävlingen innan han dyker in men ingen kan förutsäga vilken tävling som kan visas från ingenstans. Om nya konkurrenter introducerar nya funktioner som du måste duplicera, se avsnitten om funktionsändringar och prioritetsmatchningar ovan.
rusar processen
många mjukvaruprojekt börjar som visionen för en person eller ett team som vill fixa något. De kommer med en fras som” Snapchat för Y ”eller” Uber för Y ” och förväntar sig sedan att produktteamet är lika lyhörd som Snapchat eller Uber. Problemet är att räkna ut projektets omfattning, skissa dataflödena och föreställa sig användargränssnittet är ofta tio gånger så mycket arbete som att skriva koden. Men imagineers vill gå från ide till kod direkt.
wireframes, databasschema och användarhistorier är inte bara handvinkande utan en viktig del av jobbet. Men de flesta vill tro att ett mjukvaruprojekt bara skriver kod för att genomföra en ide.
falsk tro på kraften i programvara
Dreamers har ofta orealistiska övertygelser om kraften i programvara för att förändra världen. Många föreställde sig att sociala medier skulle förena oss men på något sätt är det bara utsatta fellinjer som alltid var uppenbara. Mjukvaruprojekt börjar ofta med gliddäck som lovar att revolutionera något hörn av världen. När knuffande bitar i en databas inte förvandla någon, ja, människor blir arg, uttråkad, förvirrad eller värre. De säger att programvaran är trasig eftersom den inte levererar den magiska omvandlingen som alla förväntade sig.
många mjukvaruprojekt kan kompilera, passera QA, skicka och till och med få anständiga recensioner men i slutändan misslyckas med att uppnå några av löftena på gliddäcket, eftersom de förändringar i världen är omöjliga.
onda underleverantörer
vi älskar de leverantörer som producerar bibliotek och verktyg som gör det möjligt för oss att skapa magi med bara några rader kod. Ibland får de Vind av sin makt och använder den för att förstöra ett projekt. Budgetbladet för version 1.0 var så bra att ledningen inte tvekade att godkänna version 2.0. Då beslutar säljaren att pressa oss genom att tredubbla eller femdubbla priset.
denna effekt kan kännas även när leverantörerna inte gör det med avsikt. Gratis nivåer kan få ett projekt att se väldigt billigt ut. Sedan när efterfrågan stiger och den andra versionen expanderar efterfrågan, sparkar de reala priserna in.
havsförändring
under ett år med pandemier och protester har ingenting förändrats snabbare än tidsandan. Gjorde projektet starka integritetsskydd till en central funktion? Whoop. Pandemin har gjort alla intresserade av kontaktspårning. Vill någon fokusera på affärsresor? Whoop. Hotellbranschen har kollapsat. Större mjukvaruprojekt som kan ta ett år eller längre riskerar att uppstå av katastrofala händelser. Det som verkade som en underbar ide i början kan verka hopplöst förlorat och frånkopplat när det är dags att gå live.
tekniska förändringar
det är inte bara förändringar i världen som helhet. Tidvattenförändringar i teknikgemenskapen kan ha samma effekt. NoSQL var en gång ett geni idea som skulle befria oss från relations schema. Då insåg någon att filerna uppblåste eftersom varje post hade ett lokalt schema. Ett bra agilt utvecklingsteam kan skifta när tekniska havsförändringar förändrar ledarskapets och kundernas attityder. Men även de mest smidiga lagen kan inte hantera stora SKIFT som suger all luft ur sina arkitektoniska planer. Systemet byggdes förutsatt att X var en bra ide och plötsligt är X Smuts. Ibland är det bäst att spränga det och stjärna igen.
för många tillägg
vissa mjukvaruprojekt börjar bra och till och med skickas framgångsrikt. Sedan lägger någon till en extra funktion eller tre, ympning ny kod på den befintliga versionen på ett sätt som koden fortsätter att halta längs. Heroiska utvecklare kan dra av detta flera gånger, särskilt om den ursprungliga arkitekten planerade bra. Men vid någon tidpunkt smuler grunden. Kanske kan databasen inte hantera lasten. Kanske finns det för många kopplingar som behövs för att tillfredsställa de olika frågorna. Bra programvara kan bli för fet, ibland tack vare små förbättringar som drev den över kanten.
flytta mål inlägg
de ursprungliga planerna kallas för en databas för att spåra kundens utgifter för att hjälpa till med marknadsplaner. Sedan lade något geni till en funktion som använder artificiell intelligens för att korrelera utgifterna med väderprognosen. Eller någon annan ville att programvaran automatiskt skulle bjuda på sökmotorannonser. Ändra destinationen kan upend ett projekt.
det är sällsynt att förändringarna förstör saker på egen hand. Men nya mål kan avslöja svagheter och utlösa fellägen. Kanske är laget nu för litet för att slutföra projektet framgångsrikt. Kanske är de tekniska grunden väldigt ineffektiva för det nya tillvägagångssättet. Det är svårt för alla att förutse fretful combinatorics när beslutet fattas för att ändra målen.