Att ta programmering till det extrema

Mansour Raad hade ett stort problem. Hans nystartade företag, DiscoverCast, utvecklade programvara för kollisionsdetektering för flygbranschen – misstag i koden kan kosta liv. Men pengarna tog slut efter en första finansieringsomgång, och att anställa ytterligare programmerare för att slutföra en felsäker version var uteslutet.

Så Raad startade en relativt ny kodningsdisciplin som kallas extrem programmering. Istället för att arbeta ensam med individuella uppdrag, kopplade programmerare ihop, den ene skrev kod medan den andra tittade på och kritiserade, vilket gav både ett kritiskt öga och en kritiskt viktig backup. [Min fru] fick ett barn, men projektet var tvungen att fortsätta, säger Raad. Eftersom jag visade det för andra människor kunde någon kliva in i mina skor. Företaget höll deadlines utan att antalet fel ökade på grund av kommunikationen.

De flesta programmerare är inte mer nöjda med programvarans kvalitet än sina kunder. Nu försöker ett växande antal hitta sätt att skapa solid mjukvara på en marknad som förväntar sig nya produkter och förbättringar och vill ha dem snabbt. Mjukvaruföretag vänder sig allt mer till utvecklingsstrategier med namn som agil utveckling och extrema programmeringsadrenalinladdade slagord som är väl lämpade för kodarnas självbild som robusta hjältar i informationsåldern. I verkligheten signalerar trenden – som har en lång historia – ett avvisande av primadonnaprogrammering till förmån för lagarbete och samarbete.

I mjukvaruindustrin har buggykod länge accepterats som ett faktum i livet, om än en försvårande och dyr sådan ( se varför programvara är så dålig, BARN juli/augusti 2002 ). Problemet är att i mjukvara litar folk för mycket på sin egen uppfinningsrikedom, säger Michael Stiefel, en konsult som utbildar kunder i metoder för tillförlitlighet av programvara. Jag skulle se alla dessa unga killar i 20-årsåldern göra samma misstag som vi gjorde på 70- och 80-talen, och jag undrar varför vi måste gå igenom allt detta igen.

För att minska felen bjuder reformatorer på tillvägagångssätt för mjukvaruteknik, kända i branschen som agil utveckling - som stressar lagarbete, samarbete med slutanvändare och ett flexibelt förhållningssätt till förändring. För att bygga sin programvara för att undvika kollisioner använde Raads företag en typ av agil utveckling, kallad extrem programmering, som betonar konstant testning såväl som samarbete.

Om du kan tillämpa [en samarbetsmiljö] med sin fulla kraft kommer kvaliteten på produkterna att bli bättre, säger Michele Marchesi, en ledande förespråkare för extrem programmering och professor i elektroteknik vid University of Cagliari i Italien.

En av de mest kraftfulla aspekterna av agil programmering är så kallad peer-programmering, där utvecklare samarbetar och turas om att skriva kod och förklara dess logik för den andre. Par är tillfälliga, periodvis delas och byts för att uppmuntra till ännu mer interaktion. Nya ögon undersöker varje kod, vilket skapar en process av kontinuerlig granskning.

Två personer kan studsa idéer från varandra, säger Frank Arkell, chefsingenjör hos försvarsentreprenören General Dynamics Decision Systems, som har använt samarbetstekniker i två decennier. För att hålla team fräscha ändrar General Dynamics dem för varje projekt.

En annan fördel med peer-programmering? Grupptryck. Ingen vill vara personen som slappar av, så båda arbetar hårdare, säger Scott W. Ambler, ordförande för Ronin International och författare och talare om agil utveckling.

Sätt på prov

Samarbeten förändrar också hur programvara testas. Traditionellt har testning varit en process i två steg. Först skriver programmerare kod baserat på krav. Sedan testar en separat grupp resultatet. Men när programvara innehåller miljontals rader kod, är tvåstegsprocessen analog med att designa en bil på papper, bygga den och sedan kontrollera om designen fungerade.

Det tillvägagångssättet fungerade helt enkelt inte för utvecklare som Nicholas Stamos, teknisk chef för Waltham, MA-baserade Phase Forward. Phase Forward utvecklar programvara för att köra farmaceutiska kliniska prövningar, och dess produkter måste klara de stränga kraven från U.S. Food and Drug Administration.

Stamos säger att Phase Forward uppfyller dessa krav, delvis på grund av ett nära och konstant samarbete mellan företagets programmerare och kvalitetssäkringspersonal. Man kan inte kasta den över akterspegeln och hoppas, säger han. Kvalitet måste byggas in från dag ett. När programmerare slutför en komponent kontrollerar kvalitetsteamet deras arbete. Sedan byter lagen plats mot ytterligare en omgång av buggfixar. Slutligen testas den integrerade applikationen för att hitta problem med interaktionen mellan komponenter. Istället för den gamla tvåstegsmetoden blir testning en interaktiv, pågående process.

Vissa företag försöker ett liknande iterativt tillvägagångssätt, inte bara för att testa, utan för att designa kod i första hand. Cognizant Technology Solutions, ett konsultföretag baserat i Teaneck, NJ, har upptäckt att befintliga metoder att börja med formella specifikationer och sedan skriva kod för att tillfredsställa dem kan ha fungerat för 20 eller 30 år sedan. Men i en värld som körs på webben och behöver flexibilitet, kan formellt betyda stel.

När vi försökte använda de traditionella processerna för dessa nyare typer av projekt blev kunderna antingen riktigt frustrerade för att vi tvingade dem att frysa processen eller så skulle projektteamen helt enkelt inte följa processen, säger Cognizants vd Kumar Mahadeva. Istället använder projekt en serie prototyper följt av en industrialiseringscykel, vilket låter företaget hantera plötsliga förändringar från kunder på ett sätt som har mindre inverkan på tillförlitligheten än att justera ett program efter att det är klart. Framtida användare ger en stadig ström av feedback när applikationen tar form.

Men de yttersta gränserna för mjukvarans kvalitet kanske inte ligger i programmerarnas kompetens eller styrkan i utvecklingsprocessen. Detta är den gåta som vi och många tillverkare står inför idag: vad är en acceptabel kvalitetsnivå? säger James Hymel, chef för programvaruteknik på Motorola. Om du har konkurrenter som visar sig vara söta, billiga, men buggiga [produkter] och kunderna säger att det är acceptabelt – det vill säga att de spenderar sina pengar på dem – skulle du bli utmanad.

Med metoder som agil utveckling, partnerskap för utveckling och testning och involvering av slutanvändare tar programvaruutvecklare steg för att förbättra sin produkt. Men i slutändan kan den största begränsningen för kvalitet vara samma personer som kräver det högst: konsumenterna.

Dölj