de mythische manmonthedit

Brooks bespreekt verschillende oorzaken van planningsfouten. Het meest duurzame is zijn discussie over Brooks ‘ wet:het toevoegen van mankracht aan een laat softwareproject maakt het later. Manmaand is een hypothetische eenheid van werk die het werk vertegenwoordigt dat door één persoon in één maand wordt gedaan; Brooks ‘ wet zegt dat de mogelijkheid om nuttig werk in manmaanden te meten een mythe is, en daarom het middelpunt van het boek is.

complexe programmeerprojecten kunnen niet perfect worden opgedeeld in afzonderlijke taken waaraan kan worden gewerkt zonder communicatie tussen de werknemers en zonder een reeks complexe verbanden te leggen tussen taken en de werknemers die ze uitvoeren.

daarom zal het toewijzen van meer programmeurs aan een project dat achterloopt op schema het nog later maken. Dit komt omdat de tijd die nodig is voor de nieuwe programmeurs om te leren over het project en de toegenomen communicatie overhead een steeds toenemende hoeveelheid van de beschikbare kalendertijd zal verbruiken. Als n mensen onderling moeten communiceren, als n toeneemt, neemt hun output af en als het negatief wordt, wordt het project verder vertraagd met iedereen erbij.

• groepsintercommunicatie formule: n (N − 1) / 2
• voorbeeld: 50 ontwikkelaars geven 50 · (50 – 1) / 2 = 1225 communicatiekanalen.

geen zilveren bulletEdit

Brooks voegde “No Silver Bullet — Essence and Accidents of Software Engineering”toe aan de anniversary edition van The Mythical Man—Month.”er is geen enkele ontwikkeling, noch in technologie, noch in managementtechniek, die op zichzelf zelfs maar één orde van grootte verbetering belooft binnen een decennium in productiviteit, in betrouwbaarheid, in eenvoud.”

Het argument is gebaseerd op het onderscheid tussen toevallige complexiteit en essentiële complexiteit, vergelijkbaar met de manier waarop Amdahl ‘ s wet berust op het onderscheid tussen “strikt serieel” en “parallelliseerbaar”.

the second-system effectEdit

Het second-system effect stelt voor dat wanneer een architect een tweede systeem ontwerpt, dit het gevaarlijkste systeem is dat hij ooit zal ontwerpen, omdat hij de neiging zal hebben alle toevoegingen die hij oorspronkelijk niet aan het eerste systeem toevoegde op te nemen vanwege inherente tijdsdruk. Dus, wanneer het starten van een tweede systeem, een ingenieur moet er rekening mee dat ze gevoelig zijn voor over-engineering het.

de tendens naar onherleidbaar aantal foutendit

de auteur stelt vast dat er in een geschikt complex systeem een bepaald onherleidbaar aantal fouten is. Elke poging om waargenomen fouten op te lossen heeft de neiging om te resulteren in de introductie van andere fouten.

Progress trackingEdit

Brooks schreef ” vraag: Hoe komt een groot softwareproject één jaar te laat? Antwoord: dag voor dag!”Incrementele ontsporingen op vele fronten uiteindelijk accumuleren om een grote totale vertraging te produceren. Op elk managementniveau moet voortdurend aandacht worden besteed aan het bereiken van kleine individuele mijlpalen.

conceptuele integriteitedit

om een gebruikersvriendelijk systeem te maken, moet het systeem conceptuele integriteit hebben, die alleen kan worden bereikt door architectuur van implementatie te scheiden. Een enkele hoofdarchitect (of een klein aantal architecten), die namens de gebruiker optreedt, bepaalt wat er in het systeem gaat en wat er buiten blijft. De architect of het team van architecten moet een idee ontwikkelen van wat het systeem moet doen en ervoor zorgen dat deze visie wordt begrepen door de rest van het team. Een nieuw idee van iemand kan niet worden opgenomen als het niet naadloos past bij het algehele systeemontwerp. Om een gebruiksvriendelijk systeem te waarborgen, kan een systeem doelbewust minder functies bieden dan het kan. Het punt is, als een systeem te ingewikkeld is om te gebruiken, zullen veel functies ongebruikt blijven omdat niemand tijd heeft om ze te leren.

de manualEdit

de hoofdarchitect produceert een handleiding met systeemspecificaties. Het moet de externe specificaties van het systeem in detail beschrijven, d.w.z. alles wat de gebruiker ziet. De handleiding moet worden gewijzigd als feedback komt binnen van de implementatie teams en de gebruikers.

the pilot systemEdit

bij het ontwerpen van een nieuw soort systeem zal een team een wegwerpsysteem ontwerpen (of het nu van plan is of niet). Dit systeem fungeert als een” pilot plan ” dat technieken onthult die vervolgens een volledig herontwerp van het systeem zullen veroorzaken. Dit tweede, slimmere systeem moet worden geleverd aan de klant, omdat de levering van het pilot-systeem niets anders dan pijn zou veroorzaken aan de klant, en mogelijk ruïneren de reputatie van het systeem en misschien zelfs het bedrijf.

formele documentenbewerk

elke projectmanager moet een kleine kernreeks van formele documenten maken waarin de projectdoelstellingen worden gedefinieerd, hoe deze moeten worden bereikt, wie ze zal bereiken, wanneer ze zullen worden bereikt en hoeveel ze zullen kosten. Deze documenten kunnen ook inconsistenties aan het licht brengen die anders moeilijk te zien zijn.

project estimationEdit

bij het schatten van projecttijden moet eraan worden herinnerd dat programmeerproducten (die aan betalende klanten kunnen worden verkocht) en programmeersystemen beide drie keer zo moeilijk zijn om te schrijven als eenvoudige onafhankelijke interne programma ‘ s. Er moet rekening mee worden gehouden hoeveel van de werkweek daadwerkelijk zal worden besteed aan technische kwesties, in tegenstelling tot administratieve of andere niet-technische taken, zoals vergaderingen, en met name “stand-up”-of “all-hands” – vergaderingen.

CommunicationEdit

om een ramp te voorkomen, moeten alle teams die aan een project werken op zoveel mogelijk manieren met elkaar in contact blijven—e-mail, telefoon, vergaderingen, memo ‘ s enz. In plaats van iets aan te nemen, moeten uitvoerders de architect(s) vragen om hun intentie te verduidelijken op een functie die ze implementeren, alvorens verder te gaan met een aanname die heel goed volledig onjuist zou kunnen zijn. De architect (s) zijn verantwoordelijk voor het formuleren van een groepsbeeld van het project en het communiceren met anderen.aangezien een chirurgisch team tijdens de operatie wordt geleid door één chirurg die het meest kritische werk verricht, terwijl het team wordt geleid om te helpen met minder kritieke onderdelen, lijkt het redelijk om een “goede” programmeur kritieke systeemcomponenten te laten ontwikkelen, terwijl de rest van een team voorziet in wat nodig is op het juiste moment. Bovendien, Brooks mees dat “goede” programmeurs zijn over het algemeen vijf tot tien keer zo productief als middelmatige degenen.

code freeze en system versioningEdit

Software is onzichtbaar. Daarom, veel dingen pas duidelijk worden zodra een bepaalde hoeveelheid werk is gedaan aan een nieuw systeem, waardoor een gebruiker om het te ervaren. Deze ervaring zal inzichten opleveren, die de behoeften van een gebruiker of de perceptie van de behoeften van de gebruiker zal veranderen. Het systeem moet daarom worden gewijzigd om te voldoen aan de gewijzigde eisen van de gebruiker. Dit kan slechts tot een bepaald punt gebeuren, anders kan het systeem nooit worden voltooid. Op een bepaalde datum mag het systeem niet meer worden gewijzigd en moet de code worden bevroren. Alle verzoeken om wijzigingen moeten worden uitgesteld tot de volgende versie van het systeem.

Specialized toolsEdit

in plaats van dat elke programmeur zijn eigen speciale set van tools heeft, zou elk team een aangewezen tool-maker moeten hebben die tools kan maken die zeer aangepast zijn voor de taak die het team doet, bijvoorbeeld een code generator tool die code maakt op basis van een specificatie. Daarnaast moeten systeembrede tools worden gebouwd door een common tools team, onder toezicht van de projectmanager.

verlaging van de kosten voor softwareontwikkeling edit

Er zijn twee technieken om de kosten voor softwareontwikkeling te verlagen waarover Brooks schrijft:

• Implementatoren kunnen pas worden ingehuurd nadat de architectuur van het systeem is voltooid (een stap die enkele maanden kan duren, gedurende welke tijd voortijdig ingehuurde implementatoren niets te doen hebben).
• een andere techniek die Brooks noemt is helemaal geen software te ontwikkelen, maar gewoon om het “off the shelf” te kopen indien mogelijk.