Hovedartikel: Ingen sølvkugle Brooks tilføjede”ingen sølvkugle — essens og ulykker inden for Programmelteknik “—og yderligere refleksioner over det,”‘ingen sølvkugle’ Refired ” —til jubilæumsudgaven af den mytiske Mandmåned.Brooks insisterer på, at der ikke er nogen sølvkugle – “der er ingen enkelt udvikling, hverken i teknologi eller styringsteknik, som i sig selv lover en størrelsesorden forbedring inden for et årti i produktivitet, i pålidelighed, i enkelhed.”

argumentet er afhængig af sondringen mellem utilsigtet kompleksitet og væsentlig kompleksitet, svarende til den måde, Amdahls lov er afhængig af sondringen mellem” strengt seriel “og”paralleliserbar”.

second-system effectEdit

second-system effect foreslår, at når en arkitekt designer et andet system, er det det farligste system, de nogensinde vil designe, fordi de vil have tendens til at inkorporere alle de tilføjelser, de oprindeligt ikke tilføjede til det første system på grund af iboende tidsbegrænsninger. Således, når man går i gang med et andet system, en ingeniør skal være opmærksom på, at de er modtagelige for over-engineering it.

tendensen til irreducerbart antal fejlredit

forfatteren gør observationen, at der i et passende komplekst system er et vist irreducerbart antal fejl. Ethvert forsøg på at rette observerede fejl har tendens til at resultere i indførelsen af andre fejl.

Progress trackingEdit

Brooks skrev ” spørgsmål: Hvordan kommer et stort programprojekt et år for sent? Svar: En dag ad gangen!”Inkrementelle glidninger på mange fronter akkumuleres til sidst for at producere en stor samlet forsinkelse. Der kræves fortsat opmærksomhed på at opfylde små individuelle milepæle på hvert ledelsesniveau.

konceptuel integritetredit

for at skabe et brugervenligt system skal systemet have konceptuel integritet, som kun kan opnås ved at adskille arkitektur fra implementering. En enkelt chefarkitekt (eller et lille antal arkitekter), der handler på brugerens vegne, beslutter, hvad der går i systemet, og hvad der forbliver ude. Arkitekten eller teamet af arkitekter skal udvikle en ide om, hvad systemet skal gøre og sørge for, at denne vision forstås af resten af holdet. En ny ide af nogen kan ikke medtages, hvis den ikke passer problemfrit med det overordnede systemdesign. Faktisk, for at sikre et brugervenligt system, et system kan bevidst give færre funktioner, end det er i stand til. Pointen er, at hvis et system er for kompliceret til at bruge, vil mange funktioner blive ubrugte, fordi ingen har tid til at lære dem.

manualEdit

chefarkitekten producerer en manual med systemspecifikationer. Det skal beskrive systemets eksterne SPECIFIKATIONER i detaljer, dvs.alt, hvad brugeren ser. Manualen skal ændres, når feedback kommer ind fra implementeringsteamene og brugerne.

pilotsystemetredit

når man designer en ny type system, vil et team designe et smid-væk-system (uanset om det har til hensigt at eller ej). Dette system fungerer som en” pilotplan”, der afslører teknikker, der efterfølgende vil medføre en komplet redesign af systemet. Dette andet, smartere system skal være det, der leveres til kunden, da levering af pilotsystemet ikke ville forårsage andet end smerte for kunden og muligvis ødelægge systemets omdømme og måske endda virksomheden.

formelle dokumenteredit

hver projektleder skal oprette et lille kernesæt formelle dokumenter, der definerer projektmålene, hvordan de skal nås, hvem der skal nå dem, hvornår de skal nås, og hvor meget de vil koste. Disse dokumenter kan også afsløre uoverensstemmelser, der ellers er svære at se.

project estimationEdit

ved estimering af projekttider skal det huskes, at programmeringsprodukter (som kan sælges til betalende kunder) og programmeringssystemer begge er tre gange så svære at skrive som enkle uafhængige interne programmer. Det skal huskes, hvor meget af arbejdsugen der faktisk vil blive brugt på tekniske spørgsmål i modsætning til administrative eller andre ikke-tekniske opgaver, såsom møder, og især “stand-up” eller “All-hands” møder.

CommunicationEdit

for at undgå katastrofe skal alle teams, der arbejder på et projekt, forblive i kontakt med hinanden på så mange måder som muligt—e-mail, telefon, møder, notater osv. I stedet for at antage noget, bør implementatorer bede arkitekten(e) om at afklare deres hensigt med en funktion, de implementerer, inden de fortsætter med en antagelse, der meget vel kan være helt forkert. Arkitekten(E) er ansvarlig for at formulere et gruppebillede af projektet og formidle det til andre.

det kirurgiske teamEdit

meget som et kirurgisk team under operationen ledes af en kirurg, der udfører det mest kritiske arbejde, mens teamet instrueres til at hjælpe med mindre kritiske dele, synes det rimeligt at have en “god” programmør udvikle kritiske systemkomponenter, mens resten af et team leverer det, der er nødvendigt på det rigtige tidspunkt. Derudover muses Brooks, at” gode ” programmører generelt er fem til ti gange så produktive som middelmådige.

kodefrysning og systemversionrediger

programmet er usynligt. Derfor bliver mange ting først tydelige, når der er udført en vis mængde arbejde på et nyt system, så en bruger kan opleve det. Denne oplevelse vil give indsigt, som vil ændre en brugers behov eller opfattelsen af brugerens behov. Systemet bør derfor ændres for at opfylde brugerens ændrede krav. Dette kan kun ske op til et bestemt punkt, ellers kan systemet aldrig blive afsluttet. På en bestemt dato bør der ikke tillades flere ændringer i systemet, og koden skal fryses. Alle anmodninger om ændringer skal forsinkes indtil næste version af systemet.

specialiserede værktøjeredit

i stedet for at hver programmør har deres eget specielle sæt værktøjer, skal hvert hold have en udpeget værktøjsproducent, der muligvis opretter værktøjer, der er meget tilpasset til det job, som teamet udfører, f.eks. et kodegeneratorværktøj, der opretter kode baseret på en specifikation. Derudover skal systemdækkende værktøjer bygges af et fælles værktøjsteam, der overvåges af projektlederen.

sænkning af programmeludviklingsomkostningerredit

Der er to teknikker til sænkning af programmeludviklingsomkostninger, som Brooks skriver om:

• implementatorer må kun ansættes, når systemets arkitektur er afsluttet (et trin, der kan tage flere måneder, i hvilket tidsrum for tidligt hyrede implementatorer muligvis ikke har noget at gøre).
• en anden teknik, som Brooks nævner, er slet ikke at udvikle programmer, men blot at købe det “fra hylden”, når det er muligt.