Fred Brooks ist tot, aber seine Lektionen im IT-Management werden für immer weiterleben

Fred Brooks ist tot, aber seine Lektionen im IT-Management werden für immer weiterleben

Fred Brooks starb im vergangenen Monat im Alter von 91 Jahren. Durch sein meistverkauftes Softwareentwicklungs-Managementbuch The Mythical Man-Month Essays on Software Engineering wurde er zu einer Programmier- und Management-Legende.

Im Laufe der Jahrzehnte habe ich viele Technologieführer getroffen, aber nur wenige waren so beeindruckend wie Brooks. Obwohl ich ihn oft bei Veranstaltungen gesehen habe, habe ich nur einmal mit ihm gesprochen, als er Vorsitzender der Fakultät für Informatik an der University of North Carolina war.

Einige Technologieführer, wie Steve Jobs, zeigen ihr Genie wie eine Nova. Andere, wie Brooks, sind ruhig, witzig und auf ihre Art genauso brillant.

Auch ohne das Buch wäre Brooks in der Computergeschichte als einer der führenden Köpfe bei der Entwicklung eines Betriebssystems bekannt, das auf mehr als einer Computerarchitektur verwendet werden kann: OS/360.IBM.

Assembler 360 stellte sich als meine erste Programmiersprache heraus. Faire Warnung: Die Sprache der ersten Person sollte nicht IBM 360 Assembler sein.

Was die 360 ​​Job Control Language (JCL) betrifft, erfuhr ich gleichzeitig, dass Brooks sie selbst als „die schlechteste Computerprogrammiersprache, die je von irgendjemandem irgendwo entwickelt wurde“ bezeichnete. Ich möchte nur sagen, dass es „Gründe“ gab, warum ich von Großrechnern auf Mini-Unix-Computer umgestiegen bin.

Persönlich bemerkte Brooks jedoch: „Die größte Entscheidung, die ich je getroffen habe, war, die IBM 360-Serie von einem 6-Bit-Byte auf ein 8-Bit-Byte umzustellen, was die Verwendung von Kleinbuchstaben ermöglichte. Diese Änderung hat sich über mehrere Teile hinweg ausgebreitet.“

Ja, es ist wahr. Die 8-Bit-, 16-Bit-, 32-Bit- und 64-Bit-Computerarchitekturen, mit denen wir alle aufgewachsen sind, begannen mit Brooks.

Verdammt, das Wort „Architektur“ für Computerchips und -designs stammt von ihm.

Aber woran sich die meisten von uns erinnern, ist sein Buch mit seinen prägnanten Aussagen zum Management. Wenn wir sie jetzt nur häufiger in unseren Büros einsetzen würden!

Beginnen wir mit dem bekanntesten davon: Brooks' Gesetz: „Wenn man einem verspäteten Softwareprojekt Arbeit hinzufügt, wird es spät.“

Immer wieder sehe ich, wie Unternehmen das vermasseln.

Heutzutage äußert sich dieser Fehler meistens darin, dass, oh, sagen wir mal, alle Entwickler am Freitagnachmittag im Büro erscheinen, um ihre Arbeit zu rechtfertigen und an einem Sprint zu arbeiten. Ja, eigentlich denke ich an Elon Musk und Twitter.

Aber es ist nicht nur Moschus. Wenn Sie in Ihrem Unternehmen am Ende eines Projekts immer viele zusätzliche Stunden aufwenden, um es fertig zu stellen, liegen Sie falsch. Natürlich ist es manchmal notwendig; aber wenn es zur Gewohnheit geworden ist, haben Sie ein Managementproblem.

Ein verwandter Brooksismus besagt, dass „neun Frauen in einem Monat kein Kind bekommen können“. Oder wenn Sie Musk übernehmen, können Sie auch nicht in einem Monat neun Programmierer für Tesla-Fahrzeugsysteme engagieren und ein neues Social-Media-Feature aufbauen. Oder drei Monate oder neun Monate.

Eine weitere verwandte Frage lautet: „Wie kann es sein, dass ein großes Softwareprojekt ein Jahr zu spät kommt? Antwort: Einen Tag nach dem anderen!“ Die Lösung besteht darin, sicherzustellen, dass auf jeder Führungsebene individuelle Meilensteine ​​erreicht werden.

Brooks unterstützte auch die Idee kleiner, straff geführter Softwareteams, die eine Funktionsüberlastung vermeiden und sich Zeit nehmen können.

Schließlich sagte Brooks auch: „Gute Software braucht, wie gutes Essen, Zeit, um produziert zu werden.“

Nun würden einige Leute sagen, dass Open Source das widerlegt hat. Im Open-Source-Manifest The Cathedral and the Bazaar plädierte Brooks für einen „Kathedralen“-Stil. Im Gegensatz dazu veröffentlichten locker organisierte Linux- und Open-Source-Entwickler Software-Updates früh und häufig.

Aber ist das wirklich so?

Wenn Sie sich genauer ansehen, wie Linux entwickelt wird, werden Sie viele Entwickler sehen. Aber sie werden von einer viel kleineren Gruppe von Beamten geführt, angeführt von Linus Torvalds. Die Code-Ergänzungen selbst bestehen aus vielen kleinen Änderungen.

Signifikante Änderungen, wie das Hinzufügen von Rust zu Linux oder WireGuard VPN, brauchen Jahre, um zu geschehen.

Ich denke, es sollte beachtet werden, dass im Mittelalter oft Basare auf dem Domgelände abgehalten wurden.

Brooks warnte uns auch davor, mit Silberkugeln vorsichtig zu sein.

„Es gibt keine einzige Entwicklung, weder in der Technologie noch in der Managementtechnik, die allein in einem Jahrzehnt eine Verbesserung um eine Größenordnung in Bezug auf Produktivität, Zuverlässigkeit und Einfachheit verspricht.“ Kurz gesagt, wenn jemand in Ihrem Team verspricht, dass Ihre neueste Idee, Entdeckung oder Erfindung „die Welt verändern“ wird. Glauben Sie ihnen nicht

Natürlich gibt es Entwicklungen, die die Welt verändern.

In jüngerer Zeit kommen Cloud Computing, Docker/Container und Edge Computing in den Sinn. Aber nichts davon geschah so schnell, wie Sie vielleicht denken.

Sie alle brauchten Jahre, um zu reifen und bedeutsam zu werden. Ich meine, während Dockers scheinbar plötzlicher Erfolg Sie vielleicht überrascht hat, geht seine Container-Technologie auf das Jahr 2000 und die Gefängnisse von FreeBSD zurück.

Schließlich verdankt auch DevOps, der aktuelle große Entwicklungstrend, viel Brooks' Arbeit.

Er glaubte fest daran, dass jeder über ein Projekt kommunizierte. (Es ist die Notwendigkeit einer effektiven Kommunikation, die es unmöglich macht, Softwareprobleme zu beheben, indem man mehr Arbeitsstunden dafür aufwendet.)

Natürlich machen wir das heute oft in Git und mit CI/CD-Tools, aber die Kommunikation ist heute, wie in den frühen 60er Jahren, immer noch entscheidend für den Erfolg von Programmier- und Geschäftsprojekten.

Und erfolgreich zu sein, das wollte Brooks.

Copyright © 2022 IDG Communications, Inc.