De skriver de rigtige ting

Da den 120 tons store rumfærge sidder omgivet af næsten 4 millioner pund raketbrændstof og udånder skadelige dampe, der er synligt utålmodige for at trodse tyngdekraften, tager dets kørecomputere kommandoen.

De skriver de rigtige ting

De rigtige ting sparker ind på T-minus 31 sekunder.

Da den 120 tons store rumfærge sidder omgivet af næsten 4 millioner pund raketbrændstof og udånder skadelige dampe, der er synligt utålmodige for at trodse tyngdekraften, tager dets kørecomputere kommandoen. Fire identiske maskiner, der kører identisk software, trækker oplysninger fra tusindvis af sensorer, træffer hundredvis af milli-sekunders beslutninger, stemmer om hver beslutning, tjekker med hinanden 250 gange i sekundet. En femte computer med anden software står klar til at tage kontrol, hvis de fire andre skulle fungere.



Ved T-minus 6,6 sekunder, hvis trykket, pumperne og temperaturerne er nominelle, giver computerne ordre til at tænde shuttle-hovedmotorerne-hver af de tre motorer slukker præcist 160 millisekunder fra hinanden, tons superkølet flydende brændstof hælder i forbrændingskamre, hvor skibet vugger på sit affyringsrampe, der kun holdes til jorden af ​​bolte. Da hovedmotorerne når en million kilo kraft, strammer deres udstødning til blå flammediamanter.

Mere fra Charles Fishman

Så og først derefter ved T-minus nul sekunder, hvis computerne er tilfredse med, at motorerne kører rigtigt, giver de ordre om at tænde de solide raketforstærkere. På mindre end et sekund opnår de 6,6 millioner pund fremdrift. Og i præcis samme øjeblik giver computerne ordren om, at eksplosive bolte blæser, og 4,5 millioner pund rumfartøj løfter majestætisk af sit affyringsrampe.



Det er en fantastisk visning af hardware dygtighed. Men intet menneske trykker på en knap for at få det til at ske, ingen astronaut jokker en glædespind til at sætte skytten i kredsløb.



Det rigtige er softwaren. Softwaren giver ordrer til at gimbal hovedmotorerne, og udfører den dramatiske maverulle, shuttlen gør kort tid efter, at den rydder tårnet. Softwaren kvæler motorerne for at sikre, at fartøjet ikke accelererer for hurtigt. Den holder styr på, hvor skyttelbussen er, beordrer de solide raketforstærkere til at falde væk, foretager mindre kursrettelser og leder efter cirka 10 minutter ruten ind i kredsløb mere end 100 miles op. Når softwaren er tilfreds med shuttleens position i rummet, beordrer den hovedmotorerne til at lukke - vægtløshed begynder, og alt begynder at flyde.

Men hvor meget arbejde softwaren gør, er ikke det, der gør den bemærkelsesværdig. Det, der gør det bemærkelsesværdigt, er, hvor godt softwaren fungerer. Denne software går aldrig ned. Det behøver aldrig at blive genstartet. Denne software er fejlfri. Det er perfekt, lige så perfekt som mennesker har opnået. Overvej disse statistikker: de sidste tre versioner af programmet-hver 420.000 linjer lang-havde kun en fejl hver. De sidste 11 versioner af denne software havde i alt 17 fejl. Kommercielle programmer af tilsvarende kompleksitet ville have 5.000 fejl.

Denne software er 260 kvinder og mænds arbejde baseret i en anonym kontorbygning på tværs af gaden fra Johnson Space Center i Clear Lake, Texas, sydøst for Houston. De arbejder for den indbyggede shuttle-gruppe, en afdeling af Lockheed Martin Corps space mission systems division, og deres dygtighed er verdenskendt: Shuttle-softwaregruppen er et af blot fire outfits i verden for at vinde den eftertragtede rang 5-rangering af føderale regeringers Software Engineering Institute (SEI) et mål for raffinement og pålidelighed i måden, de udfører deres arbejde på. Faktisk baserede SEI det standarder delvist fra at se den on-board shuttle gruppe gøre sit arbejde.



Gruppen skriver software så godt, fordi det er hvor godt det skal være. Hver gang det fyrer op i shuttlen, styrer deres software et udstyr på 4 milliarder dollars, livet for en halv snes astronauter og nationens drømme. Selv den mindste fejl i rummet kan have enorme konsekvenser: rumfærgen i kredsløb kører med 17.500 miles i timen; en fejl, der forårsager et timingproblem på kun to tredjedele af et sekund, sætter rumfærgen tre miles fra kurs.

NASA ved, hvor god softwaren skal være. Inden hver flyvning flyver Ted Keller, den øverste tekniske chef for den indbyggede shuttle-gruppe, til Florida, hvor han underskriver et dokument, der bekræfter, at softwaren ikke vil bringe shuttle'en i fare. Hvis Keller ikke kan gå, dikterer en formel rækkefølge, hvem der kan skrive under i hans sted.

Bill Pate, der har arbejdet med rumfartssoftwaren i løbet af de sidste 22 år, [/url] siger, at gruppen forstår indsatsen: Hvis softwaren ikke er perfekt, kan nogle af de mennesker, vi går til møder med, dø.

Software er alt. (Det er også kedeligt.)



I den menneskelige teknologis historie er intet blevet så vigtigt så hurtigt som software.

Stort set alt - fra det internationale monetære system og større kraftværker til blendere og mikrobølgeovne - kører på software. I kontorbygninger styres elevatorer, lys, vand, klimaanlæg alle af software. I biler styres transmissionen, tændingstiming, airbag, selv dørlåse af software. I de fleste byer er det også lyskrydsene. Næsten hver skriftlig kommunikation, der er mere kompliceret end et postkort, afhænger af software; hver telefonsamtale og hver pakkelevering natten over kræver det.

Software er alt. Det er også dumt.

Det er som før-sumerisk civilisation, siger Brad Cox, der skrev softwaren til Steve Jobs NeXT-computer og er professor ved George Mason University. Den måde, vi bygger software på, er i jæger-samlerstadiet.

John Munson, softwareingeniør og professor i datalogi ved University of Idaho, er ikke helt så generøs. Hule kunst, siger han. Det er primitivt. Vi underviser angiveligt i datalogi. Der er slet ingen videnskab her.

Software kan drive den postindustrielle verden, men oprettelsen af ​​software er stadig en præindustriel handel. Ifølge SEI's undersøgelser sidder næsten 70% af softwareorganisationer fast i de to første niveauer af SEI's sofistikerede skala: kaos og lidt bedre end kaos. Situationen er så alvorlig, et par softwarepionerer fra virksomheder som Microsoft har brudt væk for at lære kunsten at oprette software (se Drop and Code me Twenty!)

Mark Paulk, et højt medlem af SEI Technical, siger, at softwarens succes gør sine svagheder endnu mere dramatiske. Vi har udviklet softwareprodukter, der er enormt komplekse og enormt kraftfulde. Vi er kritisk afhængige af det, siger Paulk. Alligevel klager alle over, hvor dårlig software er, med alle fejlene. Hvis du købte en bil med 5.000 fejl, ville du blive meget ked af det.

I denne softwaremorasse skiller den indbyggede shuttle-gruppe sig ud som en undtagelse. For ti år siden blev shuttle-gruppen betragtet som verdensklasse. Siden har den reduceret sin egen fejlprocent med 90%.

For at være så god, skal den indbyggede shuttle-gruppe være meget anderledes-modsætningen til softwarekoderne, der kører pizza hele natten, og som har fanget den offentlige fantasi. For at være så god skal den indbyggede shuttle-gruppe være meget almindelig-ikke kan skelnes fra enhver fokuseret, disciplineret og metodisk styret kreativ virksomhed.

Faktisk tilbyder gruppen et sæt lærebogstimer, der gælder lige så meget for programmører i særdeleshed og producenter generelt. Et kig på den kultur, de har bygget, og den proces, de har perfektioneret, viser, hvad softwareskrivning skal blive, hvis software skal realisere sit løfte, og illustrerer, hvad næsten enhver teambaseret operation kan gøre for at øge dens ydeevne for at opnå næsten perfekte resultater .

Software til voksne

Forsendelseshelvede fortsatte i dag. Slib, mal, mal. Vi når det aldrig. Har jeg sagt det allerede? Hvorfor undervurderer vi altid vores forsendelsesplaner? Jeg forstår bare ikke. Ind kl. 9:30; ud kl. 23:30 Dominos til middag. Og tre kostkoks.

Nej, det er ikke den indbyggede shuttle-gruppe. Det er Douglas Couplands Microserf's, en realistisk fiktiv beretning om livet i softwaren-hurtigbane. Og det er det dominerende billede af softwareudviklingsverdenen: Gen-Xers sports-T-shirts og distraheret udseende, der presser for meget heroisk kodeskrivning ind på for lidt tid; rulleskøjter og mountainbikes gemt i hjørner; pizzakasser og Starbucks -kopper kasseres i konferencelokaler; duellerende melodier fra Smashing Pumpkins, Alanis Morrisette og Fugees. Det blev verden berømt, romantisk, endda uundgåelig af historier fra Sun Microsystems, Microsoft og Netscape.

grønne coca-cola flasker

Det er ikke historien om den indbyggede shuttle-gruppe. Deres kvarterer er en undersøgelse af fodgænger med hvid krave. Det mest slående er, hvor almindelige de ser ud. Bortset fra lejlighedsvis lidt shuttle -memorabilia, kan du være på kontorer for ethvert lille firma eller regeringsorgan. Alle har sit eget lille kontor, og kontorerne har skriveborde, pc'er og sparsomme personlige artefakter. Folk går moderat klædt tøj på til arbejdet, pænt men intet prangende, bestemt ikke noget grungy.

Det er strengt taget et 8 til 5 slags sted-der er sene nætter, men de er undtagelsen. Programmørerne er intense, men lavmælte. Mange af dem har lagt mange års arbejde enten på IBM (som ejede shuttlegruppen indtil 1994) eller direkte på shuttle -softwaren. De er voksne, med ægtefæller og børn og lever ud over deres bemærkelsesværdige softwareprogram.

Det er kulturen: den indbyggede shuttle-gruppe producerer voksen software, og den måde, de gør det på, er ved at være voksne. Det er måske ikke sexet, det er muligvis ikke en kodende egotur-men det er softwarens fremtid. Når du er klar til at tage det næste trin - når du skal skrive perfekt software i stedet for software, der bare er god nok - så er det tid til at vokse op.

Ted Keller, 48, gruppens øverste tekniske chef, ligner og lyder som forstander på et lille privat gymnasium. Det er Kellers opgave at sørge for, at softwaren bliver leveret til tiden med alle sine muligheder uden hensyn til græstørvskampe. Han er en kompakt, skaldet mand, lidt officiøs og snedig, egenskaber enhver astronaut ville finde betryggende. Han har en blid, nørdet sans for humor, ikke så meget med udenforstående, men med sin skare.

Det kommer ud i et møde mellem medlemmer af softwaregruppen og deres NASA -kolleger. Det afholdes i et lille konferencelokale fyldt med 22 personer og en overheadprojektor. Flere gange fra bagsiden af ​​rummet udsender Keller en skæv bemærkning om hastigheden på kodelevering eller detaljerne i nogle specifikationer, og rummet lysner af latter.

Ellers er det timelange møde ædru og afslørende, et kort vindue om kulturen. For det første er 12 af de 22 personer i lokalet kvinder, mange af dem ledere eller højtstående teknisk personale. Den indbyggede shuttle-gruppe, med sin stabilitet og professionalisme, synes særligt tiltalende for kvindelige programmører.

hvor blev tumblr -porno af?

For den anden er det en øvelse i rækkefølge, detaljer og metodisk gentagelse. Mødet er en klassisk NASA -forestilling - en øvelse til et næsten identisk møde flere uger væk. Den består i at gå gennem en enorm pakke med data og visninger - grafer, der beskriver softwarens fremskridt og status linje for linje. Bortset fra Kellers lejlighedsvise sider er tonen forretningsmæssig, næsten formel, visningen - grafer blinker forbi så hurtigt som de kan læses, en sløring af akronymer, grafer og diagrammer.

Det, der foregår her, er den slags møtrikker, der definerer drevet til gruppens perfektion-et drev, der aggressivt er intolerant over for egodrevne hotshots. I shuttle -gruppens kultur er der ingen superstjerne programmører. Hele tilgangen til at udvikle software er bevidst designet til ikke at stole på en bestemt person.

Mere fra dette nummer


  • Hvorfor Shuttle er venstrehåndet
  • Han vender ideer ind i virksomheder - med nettofart
  • Drop And Code Me Twenty
  • Hvad kommer efter succes?
  • Viruset til marketing

Og kulturen er lige så intolerant over for kreativitet, den individuelle kodning blomstrer og stilarter, der er signaturen for software-verdenen hele natten. Folk spørger, kvæler denne proces ikke kreativiteten? Du skal gøre præcis, hvad manualen siger, og du har en, der kigger dig over skulderen, siger Keller. Svaret er, ja, processen kvæler kreativiteten.

Og det er netop pointen - du kan ikke få folk til at freelancere sig gennem softwarekode, der flyver et rumskib, og derefter, med folks liv afhængig af det, prøv at lappe det, når det er i kredsløb. Houston, vi har et problem, kan være en god film; det er ingen måde at skrive software på. Folk skal kanalisere deres kreativitet til at ændre processen, siger Keller og ikke ændre softwaren.

De stramme restriktioner, gruppen praktiserer, kan gøre sirenen til rock n roll -softwareverdenen svær at modstå. Quinn Larson, 34, havde arbejdet med shuttle -software i syv år, da han sidste januar forlod for at gå på arbejde for Micron Technology i Boise, Idaho, og automatisere fremstillingen af ​​Microns -hukommelseschips.

Hos Micron fik Larson til opgave at automatisere savene, der skærede færdige spånskiver til den rigtige størrelse. Skru op for programmet, du ødelægger de værdifulde wafers.

Det var op til mig at beslutte, hvad jeg skulle gøre, siger Larson. Der var ingen møder, der var ingen journalføring. Han havde frihed; det var et rigtigt spark. Men til Larsons tankegang fokuserede kulturen ikke på, ja, de rigtige ting. Hastighed der var den største ting, siger han. Ingeniørerne vil sige, at det er vores topprioriteter, og vi skal hente dem så hurtigt som vi kan. Men det indtryk, Larson fik, var, at ingeniører ikke virkede for bekymrede over, hvor godt den færdige software rent faktisk fungerede. Grundlæggende ønskede de hurtig software - bare sæt den ud af døren.

Larson startede tilbage i shuttle-gruppen i midten af ​​august. Folkene her er bare af højeste kaliber, sagde han på sin første dag tilbage i Clear Lake.

Det er processen

Hvordan skriver de de rigtige ting?

Svaret er, det er processen. Gruppens vigtigste skabelse er ikke den perfekte software, de skriver - det er den proces, de opfandt, der skriver den perfekte software.

Det er den proces, der giver dem mulighed for at leve et normalt liv, at fastsætte deadlines, de rent faktisk overholder, at holde på budgettet, at levere software, der gør præcis, hvad det lover. Det er processen, der definerer, hvad disse kodere i de flade sletter i det sydøstlige forstæder Houston ved, at alle andre i softwareverdenen stadig famler efter. Det er processen, der tilbyder en skabelon til enhver kreativ virksomhed, der leder efter en metode til at producere konsekvent - og konsekvent forbedring - kvalitet.

Processen kan reduceres til fire enkle forslag:

1. Produktet er kun så godt som planen for produktet.I den indbyggede shuttle-gruppe sker omkring en tredjedel af processen med at skrive software, før nogen skriver en linje kode. NASA og Lockheed Martin -gruppen er enige i de mindste detaljer om alt, hvad den nye kode skal gøre - og de forpligter den forståelse til papir med den slags specificitet og præcision, der normalt findes i tegninger. Intet i specifikationerne ændres uden aftale og forståelse fra begge sider. Og ingen koder ændrer en enkelt kodelinje uden specifikationer, der omhyggeligt skitserer ændringen. Tag opgraderingen af ​​softwaren, så shuttlen kan navigere med globale positioneringssatellitter, en ændring, der kun involverer 1,5% af programmet eller 6.366 linjer kode. Specifikationerne for den ene ændring kører 2.500 sider, et volumen tykkere end en telefonbog. Specifikationerne for det aktuelle program fylder 30 bind og kører 40.000 sider.

Vores krav er næsten pseudokode, siger William R. Pruett, der administrerer softwareprojektet til NASA. De siger, du skal gøre præcis dette, gøre det præcis på denne måde, givet denne betingelse og denne omstændighed.

Denne omhyggelige designproces alene er nok til at sætte shuttle -organisationen i en klasse for sig, siger John Munson fra University of Idaho. De fleste organisationer starter selv store projekter uden at planlægge, hvad softwaren skal gøre i blueprintlignende detaljer. Så efter at kodere allerede er begyndt at skrive et program, ændrer kunden travlt sit design. Resultatet er kaotisk, kostbar programmering, hvor kode konstant ændres og inficeres med fejl, selvom den bliver designet.

De fleste mennesker vælger at bruge deres penge i den forkerte ende af processen, siger Munson. I det moderne softwaremiljø bruges 80% af omkostningerne ved softwaren, efter at softwaren er skrevet første gang - de får det ikke rigtigt første gang, så de bruger tid på at piske det. I shuttle gør de det rigtigt første gang. Og de ændrer ikke softwaren uden at ændre planen. Derfor er deres software så perfekt.

2. Det bedste teamwork er en sund rivalisering.Inden for softwaregruppen er der undergrupper og subkulturer. Men det, der kan være splittende kontorpolitik i andre organisationer, er faktisk en kritisk del af processen.

Den centrale gruppe opdeles i to centrale teams: koderne - de mennesker, der sidder og skriver kode - og verifikatorerne - de mennesker, der forsøger at finde fejl i koden. De to outfits rapporterer til separate chefer og fungerer under modsatrettede marchordrer. Udviklingsgruppen formodes at levere helt fejlfri kode, så perfekt, at testerne slet ikke finder fejl. Testgruppen formodes at pille væk ved koden med flyvescenarier og simuleringer, der afslører så mange fejl som muligt. Resultatet er, hvad Tom Peterson kalder et venligt kontradiktorisk forhold.

De konkurrerer om, hvem der skal finde fejlene, siger Keller. Nogle gange kæmper de som katte og hunde. Udviklerne ønsker at fange alle deres egne fejl. Verifikatorerne bliver sure: 'Hey, giv det! Du tager væk fra vores tid til at teste softwaren! & Apos;

Udviklerne har endda påbegyndt deres egne formelle inspektioner af koden i omhyggeligt modererede sessioner, en streng korrekturlæsning, de håber vil forvirre testerne. Verifikatorerne hævder til gengæld, at de fortjener æren for nogle fejl, der er fundet, før de overhovedet begynder at teste. Fra verifikationsgruppens perspektiv, siger Pat McLellan, en senior manager, er vi klar over, at hvis der ikke var en uafhængig verifikationsgruppe, ville udviklerne have en tendens til at være mere slappe. Bare tilstedeværelsen af ​​vores gruppe gør dem mere forsigtige.

bill burr på louis ck

Resultaterne af denne venlige rivalisering: Shuttle -gruppen finder nu 85% af sine fejl, før den formelle test begynder, og 99,9%, før programmet leveres til NASA.

3. Databasen er softwarebasen.Der er softwaren. Og så er der databaserne under softwaren, to enorme databaser, encyklopædiske i deres fuldstændighed.

Den ene er kodenes historie - med hver linje kommenteret, der viser hver gang den blev ændret, hvorfor den blev ændret, hvornår den blev ændret, hvad formålet med ændringen var, hvilke specifikationsdokumenter der beskriver detaljerne. Alt, hvad der sker med programmet, er registreret i dets masterhistorie. Slægtsbogen for hver kodelinje - grunden til at det er som det er - er øjeblikkeligt tilgængeligt for alle.

Den anden database-fejldatabasen-står som en slags monument over den måde, som den indbyggede shuttle-gruppe arbejder på. Her registreres hver eneste fejl, der nogensinde er lavet under skrivning eller arbejde på softwaren, og går næsten 20 år tilbage. For hver af disse fejl registrerer databasen, hvornår fejlen blev opdaget; hvilket sæt kommandoer afslørede fejlen; hvem opdagede det; hvilken aktivitet foregik, da den blev opdaget - test, træning eller flyvning. Det sporer, hvordan fejlen blev introduceret i programmet; hvordan fejlen formåede at glide forbi filtrene, der blev oprettet på hvert trin for at fange fejl - hvorfor blev den ikke fanget under design? under udviklingskontrol? under verifikation? Endelig registrerer databasen, hvordan fejlen er rettet, og om lignende fejl muligvis er gledet gennem de samme huller.

Gruppen har akkumuleret så mange data om, hvordan den udfører sit arbejde, at den har skrevet softwareprogrammer, der modellerer kodeskrivningsprocessen. Ligesom computermodeller, der forudsiger vejret, forudsiger kodningsmodellerne, hvor mange fejl gruppen skal lave ved at skrive hver ny version af softwaren. Sandt nok, hvis koderne og testerne finder for få fejl, arbejder alle processen, indtil virkeligheden og forudsigelserne matcher.

Vi lader aldrig noget gå, siger Patti Thornton, en senior manager. Vi gør det modsatte: vi lader alt forstyrre os.

4. Fix ikke bare fejlene - rett hvad der end måtte tillade fejlen i første omgang.

Processen er så gennemgribende, at den får skylden for enhver fejl - hvis der er en fejl i softwaren, må der være noget galt med den måde, den skrives på, noget der kan rettes. Enhver fejl, der ikke blev fundet på planlægningsstadiet, er gledet gennem i det mindste nogle kontroller. Hvorfor? Er der noget galt med inspektionsprocessen? Skal et spørgsmål tilføjes til en tjekliste?

Det er vigtigt, at gruppen undgår at bebrejde folk for fejl. Processen påtager sig skylden - og det er processen, der analyseres for at opdage, hvorfor og hvordan en fejl kom igennem. På samme tid er ansvarlighed et teamkoncept: ingen person er nogensinde alene ansvarlig for at skrive eller inspicere kode. Du bliver ikke straffet for at lave fejl, siger Marjorie Seiter, et højtstående medlem af det tekniske personale. Hvis jeg laver en fejl, og andre har gennemgået mit arbejde, så er jeg ikke alene. Jeg får ikke skylden for dette.

Ted Keller tilbyder et eksempel på udbetalingen af ​​tilgangen, der involverer shuttles fjernmanipulatorarm. Vi leverede software til besætningstræning, siger Keller, der tillader astronauterne at manipulere armen og håndtere nyttelasten. Da armen kom til et bestemt punkt, stoppede den simpelthen med at bevæge sig.

Softwaren var forvirret på grund af en programmeringsfejl. Da fjernarmens håndled nærmede sig en komplet 360-graders rotation, fik fejlbehæftede beregninger softwaren til at tro, at armen var gået forbi en komplet rotation-hvilket softwaren vidste var forkert. Problemet havde at gøre med at afrunde svaret på et almindeligt matematisk problem, men det afslørede en kaskade af andre problemer.

Selvom dette ikke var kritisk, siger Keller, gik vi tilbage og spurgte, hvilke andre kodelinjer der kunne have præcis den samme slags problem. De fandt otte sådanne situationer i koden, og i syv af dem var afrundingsfunktionen ikke et problem. En af dem involverede high-gain-antennens pegerutine, siger Keller. Det er hovedantennen. Hvis det havde udviklet dette problem, kunne det have afbrudt kommunikationen med jorden på et kritisk tidspunkt. Det er meget mere alvorligt.

Måden processen fungerer på, finder den ikke kun fejl i softwaren. Processen finder fejl i processen.

Bare et softwareproblem

B-2-bombeflyet ville ikke flyve på sit jomfrufly-men det var bare et softwareproblem. Den nye Denver lufthavn var måneder forsinket åbning og millioner af dollars over budget, fordi bagagehåndteringssystemet ikke fungerede rigtigt - men det var bare et softwareproblem. I foråret sprængte European Space Agency's nye Ariane 5 -raket på sin jomfrutyr på grund af et lille softwareproblem. Forbundsregeringens store agenturer - fra IRS til National Weather Service - er besat af projekter, der er forsinkede år og hundredvis af millioner af dollars over budget, ofte på grund af simple softwareproblemer. Software bliver mere og mere almindeligt og mere og mere vigtigt, men det ser ikke ud til at blive mere og mere pålideligt.

Da resten af ​​verden kæmper med det grundlæggende, kommer den indbyggede shuttle-gruppe stadig tættere på perfekt software. De har ganske vist mange fordele i forhold til resten af ​​softwareverdenen. De har et enkelt produkt: ét program, der flyver ét rumskib. De forstår deres software indgående, og de bliver mere fortrolige med det hele tiden. Gruppen har én kunde, en smart. Og penge er ikke den kritiske begrænsning: Gruppens budget på 35 millioner dollars om året er et trivielt udsnit af NASA-tærten, men på basis af dollars pr. Linje gør det gruppen til landets dyreste softwareorganisationer.

Og det er pointen: shuttle -processen er så ekstrem, drevet af perfektion er så fokuseret, at det afslører, hvad der kræves for at opnå ubarmhjertig udførelse. De vigtigste ting, shuttle -gruppen gør - omhyggeligt at planlægge softwaren på forhånd, skrive ingen kode, før designet er færdigt, foretage ingen ændringer uden at understøtte blueprints, føre en helt nøjagtig registrering af koden - er ikke dyre. Processen er ikke engang raketvidenskab. Dens standard praksis i næsten alle ingeniørdiscipliner undtagen software engineering.

Gipset på et væg i et konferencerum fanger et uformelt slogan fra den indbyggede shuttle-gruppe essensen af ​​at holde fokus på processen: Jo før du kommer bagud, jo mere tid skal du indhente.

Charles Fishman (fish@nando.net) er en forfatter med base i Raleigh, North Carolina.