den mytiska manmånaden

Brooks diskuterar flera orsaker till schemaläggningsfel. Den mest varaktiga är hans diskussion om Brooks lag: att lägga till arbetskraft till ett sent mjukvaruprojekt gör det senare. Manmånad är en hypotetisk arbetsenhet som representerar det arbete som utförs av en person på en månad; Brooks lag säger att möjligheten att mäta användbart arbete under manmånader är en myt och är därmed bokens mittpunkt.

komplexa programmeringsprojekt kan inte helt delas upp i diskreta uppgifter som kan bearbetas utan kommunikation mellan arbetarna och utan att skapa en uppsättning komplexa samband mellan uppgifter och de arbetare som utför dem.

att tilldela fler programmerare till ett projekt som körs bakom schemat kommer därför att göra det ännu senare. Detta beror på att den tid som krävs för de nya programmerarna att lära sig om projektet och den ökade kommunikationskostnaden kommer att förbruka en ständigt ökande mängd av den tillgängliga kalendertiden. När n-personer måste kommunicera med varandra, när n ökar, minskar deras produktion och när det blir negativt försenas projektet ytterligare med varje person som läggs till.

• Gruppinterkommunikationsformel: n( n-1) / 2
• exempel: 50 utvecklare ger 50 · (50 – 1) / 2 = 1225 kanaler för kommunikation.

ingen silverbulletedit

Brooks lade till ” No Silver Bullet-Essence and Accidents of Software Engineering ”—och ytterligare reflektioner över det,”’No Silver Bullet’ Refired ” -till jubileumsutgåvan av den mytiska Manmånaden.Brooks insisterar på att det inte finns någon Silverkula – ” det finns ingen enskild utveckling, varken i teknik eller förvaltningsteknik, som i sig lovar till och med en storleksordning förbättring inom ett decennium i produktivitet, i tillförlitlighet, i enkelhet.”

argumentet bygger på skillnaden mellan oavsiktlig komplexitet och väsentlig komplexitet, på samma sätt som Amdahls lag bygger på skillnaden mellan ”strikt seriell” och ”parallelliserbar”.

second-system effectEdit

second-system effect föreslår att när en arkitekt utformar ett andra system är det det farligaste systemet de någonsin kommer att designa, eftersom de tenderar att införliva alla tillägg som de ursprungligen inte lade till i det första systemet på grund av inneboende tidsbegränsningar. Således, när man går ombord på ett andra system, en ingenjör bör vara medveten om att de är mottagliga för över engineering det.

tendensen till irreducible antal felredigera

författaren gör observationen att i ett lämpligt komplext system finns ett visst irreducibelt antal fel. Varje försök att åtgärda observerade fel tenderar att resultera i införandet av andra fel.

Progress trackingEdit

Brooks skrev ” fråga: Hur blir ett stort mjukvaruprojekt ett år sent? Svar: En dag i taget!”Inkrementella glidningar på många fronter ackumuleras så småningom för att ge en stor Total fördröjning. Fortsatt uppmärksamhet på att möta små enskilda milstolpar krävs på varje ledningsnivå.

Conceptual integrityEdit

för att skapa ett användarvänligt system måste systemet ha konceptuell integritet, vilket endast kan uppnås genom att separera arkitektur från implementering. En enda chefsarkitekt (eller ett litet antal arkitekter), som agerar på användarens vägnar, bestämmer vad som går i systemet och vad som stannar ute. Arkitekten eller teamet av arkitekter bör utveckla en uppfattning om vad systemet ska göra och se till att denna vision förstås av resten av teamet. En ny ide av någon kanske inte ingår om den inte passar sömlöst med den övergripande systemdesignen. För att säkerställa ett användarvänligt system kan ett system medvetet ge färre funktioner än det kan. Poängen är att om ett system är för komplicerat att använda, kommer många funktioner att gå oanvända eftersom ingen har tid att lära sig dem.

manualEdit

chefsarkitekten producerar en manual med systemspecifikationer. Det bör beskriva systemets externa SPECIFIKATIONER i detalj, dvs allt som användaren ser. Manualen bör ändras när feedback kommer in från implementeringsteamen och användarna.

pilot systemEdit

vid utformning av en ny typ av system kommer ett team att utforma ett kasta-away-system (oavsett om det avser eller inte). Detta system fungerar som en” pilotplan ” som avslöjar tekniker som därefter kommer att orsaka en fullständig redesign av systemet. Detta andra, smartare system borde vara det som levereras till kunden, eftersom leverans av pilotsystemet inte skulle orsaka annat än ångest för kunden och eventuellt förstöra systemets rykte och kanske till och med företaget.

formella dokumentredigera

varje projektledare ska skapa en liten uppsättning formella dokument som definierar projektmålen, hur de ska uppnås, vem som ska uppnå dem, när de ska uppnås och hur mycket de kommer att kosta. Dessa dokument kan också avslöja inkonsekvenser som annars är svåra att se.

Project estimationEdit

Vid beräkning av projekttider bör man komma ihåg att programmeringsprodukter (som kan säljas till betalande kunder) och programmeringssystem är båda tre gånger så svåra att skriva som enkla oberoende interna program. Man bör komma ihåg hur mycket av arbetsveckan som faktiskt kommer att spenderas på tekniska frågor, i motsats till administrativa eller andra icke-tekniska uppgifter, till exempel möten, och särskilt ”stand-up” eller ”all-hands” – möten.

CommunicationEdit

för att undvika katastrof bör alla team som arbetar med ett projekt förbli i kontakt med varandra på så många sätt som möjligt—e-post, telefon, möten, noteringar etc. Istället för att anta något, bör implementatörer be arkitekten att klargöra sin avsikt med en funktion de implementerar innan de fortsätter med ett antagande som mycket väl kan vara helt felaktigt. Arkitekten / arkitekterna ansvarar för att formulera en gruppbild av projektet och kommunicera det till andra.

den kirurgiska teamEdit

mycket som ett kirurgiskt team under operationen leds av en kirurg som utför det mest kritiska arbetet, samtidigt styra laget att hjälpa till med mindre kritiska delar, verkar det rimligt att ha en ”bra” programmerare utveckla kritiska systemkomponenter medan resten av ett team ger vad som behövs vid rätt tidpunkt. Dessutom anser Brooks att ”bra” programmerare i allmänhet är fem till tio gånger så produktiva som mediokra.

kod frysa och system versioningEdit

programvara är osynlig. Därför blir många saker bara uppenbara när en viss mängd arbete har gjorts på ett nytt system, så att en användare kan uppleva det. Denna erfarenhet kommer att ge insikter, vilket kommer att förändra en användares behov eller uppfattningen av användarens behov. Systemet bör därför ändras för att uppfylla användarens ändrade krav. Detta kan bara ske upp till en viss punkt, annars kan systemet aldrig slutföras. Vid ett visst datum bör inga fler ändringar tillåtas i systemet och koden ska frysas. Alla förfrågningar om ändringar bör försenas till nästa version av systemet.

Specialverktygsredigera

istället för att varje programmerare har sin egen speciella uppsättning verktyg, bör varje lag ha en utsedd verktygsmakare som kan skapa verktyg som är mycket anpassade för det jobb som laget gör, t.ex. ett kodgeneratorverktyg som skapar kod baserat på en specifikation. Dessutom bör systemomfattande verktyg byggas av ett gemensamt verktygsteam som övervakas av projektledaren.

Sänka programvaruutvecklingskostnaderredigera

det finns två tekniker för att sänka mjukvaruutvecklingskostnader som Brooks skriver om:

• implementatörer kan anställas först efter att systemets arkitektur har slutförts (ett steg som kan ta flera månader, under vilken tid tidigt anställda implementatörer kanske inte har något att göra).
• en annan teknik som Brooks nämner är inte att utveckla programvara alls, utan helt enkelt att köpa den ”från hyllan” när det är möjligt.