Fred Brooks dog förra månaden vid 91 års ålder. Genom sin bästsäljande ledningsbok för mjukvaruutveckling, The Mythical Man-Month Essays on Software Engineering, blev han en programmerings- och managementlegend.
Under decennierna har jag träffat många tekniska ledare, men få var så imponerande som Brooks. Även om jag har sett honom många gånger vid evenemang, pratade jag bara med honom en gång när han var ordförande för datavetenskapsavdelningen vid University of North Carolina.
Vissa tekniska ledare, som Steve Jobs, visar upp sitt geni som en nova. Andra, som Brooks, är tysta, kvicka och lika briljanta på sitt eget sätt.
Även utan boken skulle Brooks vara känd i datorhistorien för att vara en av de ledande i att utveckla ett operativsystem som skulle kunna användas på mer än en datorarkitektur: OS/360.IBM.
Assembler 360 visade sig vara mitt första programmeringsspråk. Rättvis varning: Förstapersonsspråk bör inte vara IBM 360 Assembler.
När det gäller 360 Job Control Language (JCL) lärde jag mig samtidigt att Brooks själv kallade det "det sämsta datorprogrammeringsspråket som någonsin utarbetats av någon, var som helst." Jag ska bara säga att det fanns "anledningar" till att jag bytte från stordatorer till mini Unix-datorer.
Men personligen noterade Brooks, "Det största beslutet jag någonsin tagit var att ändra IBM 360-serien från en 6-bitars byte till en 8-bitars byte, vilket möjliggjorde användningen av små bokstäver. Denna förändring har spridit sig över delar".
Om sant. 8-bitars, 16-bitars, 32-bitars och 64-bitars datorarkitekturer som vi alla växte upp med började med Brooks.
Heck, själva ordet "arkitektur" för datorchips och design kommer från honom.
Men vad de flesta av oss minns är hans bok, med dess pittige ledningsuttalanden. Om vi bara använde dem mer på våra kontor!
Låt oss börja med den mest kända av dessa: Brooks' lag: "Att lägga till arbetskraft till ett sent mjukvaruprojekt gör det sent."
Gång på gång ser jag företag skruva ihop det här.
Oftare än inte nuförtiden visar detta misstag sig genom att insistera på att, låt oss bara säga, alla utvecklare dyker upp på kontoret på fredag eftermiddag för att motivera sitt arbete och arbeta på en sprint. Ja, faktiskt, jag tänker på Elon Musk och Twitter.
Men det är inte bara Musk. Om du i ditt företag alltid ägnar en massa extra timmar i slutet av ett projekt för att få dem gjorda, har du fel. Visst, ibland är det nödvändigt; men om det har blivit en vana har du ett ledningsproblem.
En relaterad Brooksism är att "nio kvinnor inte kan få barn på en månad." Eller, genom att ta över för Musk, kan du inte heller ta in nio Tesla-fordonssystemprogrammerare och bygga en ny funktion för sociala medier på en månad. Eller tre månader, eller nio månader, för den delen.
En annan relaterad fråga är: "Hur kan ett stort programvaruprojekt bli ett år försenat? Svar: en dag i taget!" Lösningen är att säkerställa att individuella milstolpar uppnås på varje ledningsnivå.
Brooks stödde också idén om små, tätt hanterade mjukvaruteam som kan undvika överbelastning av funktioner och ta sin tid.
Trots allt sa Brooks också, "bra mjukvara, som god mat, tar tid att producera."
Nu skulle vissa säga att öppen källkod har motbevisat det. I manifestet med öppen källkod The Cathedral and the Bazaar förespråkade Brooks en "katedralstil". Däremot släppte löst organiserade Linux- och öppen källkodsutvecklare programuppdateringar tidigt och ofta.
Men är det verkligen så?
Om du tittar närmare på hur Linux utvecklas kommer du att se många utvecklare. Men de drivs av en mycket mindre grupp tjänstemän med Linus Torvalds i spetsen. Kodtilläggen i sig består av många små ändringar.
Betydande förändringar, som att lägga till Rust till Linux eller WireGuard VPN, tar år att hända.
Jag tycker att det bör noteras att det under medeltiden ofta hölls basarer på katedralens område.
Brooks varnade oss också för att vara försiktiga med silverkulor.
"Det finns inte en enda utveckling, vare sig inom teknik eller ledningsteknik, som ensam lovar en förbättring i storleksordningen på ett decennium när det gäller produktivitet, tillförlitlighet, enkelhet." Kort sagt, om någon i ditt team lovar att din senaste idé, upptäckt eller uppfinning kommer att "förändra världen." Tro dem inte
Naturligtvis finns det utvecklingar som förändrar världen.
På senare tid kommer cloud computing, Docker/containers och edge computing att tänka på. Men inget av det hände så snabbt som man kan tro.
De tog alla år att mogna och bli betydelsefulla. Jag menar, även om Dockers till synes plötsliga framgång kan ha överraskat dig, så går dess containerteknologi tillbaka till 2000 och FreeBSDs fängelsehus.
Slutligen, DevOps, den nuvarande stora utvecklingstrenden, är också skyldig Brooks arbete mycket.
Han var övertygad om att alla kommunicerade om ett projekt. (Det är behovet av effektiv kommunikation som gör det omöjligt att åtgärda programvaruproblem genom att lägga mer mantimmar på dem.)
Naturligtvis gör vi ofta detta nu i Git och med CI/CD-verktyg, men kommunikation nu, som det var i början av 60-talet, är fortfarande avgörande för framgången för programmerings- och affärsprojekt.
Och att vara framgångsrik är vad Brooks ville.
Copyright © 2022 IDG Communications, Inc.