Die 10 Grundsätze der Google Test- und Entwicklungskultur

…
Fortsetzung von Google Test- und Entwicklungskultur
…

Die 10 Grundsätze der Google Software Engineering Kultur:
Single source code repository for all Google code
Jeder Entwickler kann den gesamten Quellcode von Google einsehen. Es gibt dabei keine Beschränkungen und funktioniert ähnlich wie bei Open Source Projekten. Ich kam nicht darum herum, Bernhard Seefeld zu fragen, ob ein Google Ingenieur, der lange genug bei Google arbeitet, aufgrund des offenen Codes in der Lage wäre, ein Reengineering des Google Ranking Algorithmus vorzunehmen. Dies wurde von ihm ganz klar bejaht. Zumindest wird technisch nichts unternommen, um aktiv zu verhindern, dass jemand den gesamten Quellcode studiert. Dies funktioniert primär deswegen, weil die Mitarbeiter die Offenheit auch respektieren und internes nicht nach aussen tragen.

Persönlich gehe ich davon aus, dass dies faktisch trotzdem unmöglich ist. Ich habe selbst bei führenden Google Ingenieuren festgestellt, welche seit 7 Jahren oder länger dabei sind (was bei Google eine Ewigkeit ist), dass sie nie alle Aspekte des Algorithmus kennen. Ein System, an welchem Tausende Programmierer während Jahren gearbeitet haben, ist zu komplex, als dass sich ein einzelner alles merken könnte. Zudem ändert sich zu viel zu schnell. Wer sich also mit der Hoffnung auf den Schlüssel zum Google Algorithmus bei Google bewirbt, sollte seine Motivation gut hinterfragen…

Developers can checkin fixes for any Google product
Jeder Programmierer, welcher irgendwo einen Fehler entdeckt, kann diesen selber beheben. Aber vor der Freischaltung muss zuerst das betroffene Projektteam informiert werden (in der Regel diejenige Person, welche am meisten am betroffenen Teil gearbeitet hat). Jedes Projekt hat auch eine Mailinglist und jeder, der sich dafür interessiert, kann sich in diese eintragen.

You can build any Google product in three steps
Die drei Stufen sind get, configure, make.

Uniform coding standards across the company
Die Programmierstandards werden einerseits über Tools geprüft, andererseits wird die Einhaltung der Standards über die Reviews sichergestellt.

Mandatory code reviews before checkins
Jede Arbeit wird von einer zweiten Person geprüft. Es gibt keinen Code, der nicht zumindest von einer zweiten Person verstanden worden wäre.

Pervasive unit testing
Es wird fast soviel Unit Testcode geschrieben wie normalen Code. Dies ist zwar sehr aufwändig, erleichtert aber die Arbeit ungemein. Bei jeder Änderung kann über die Unit Tests geprüft werden, ob irgendein Teil des Codes nicht mehr funktioniert.

Tests run continuously, emails sent to developers if any failures
Bevor Code online geht, wird dieser nochmals automatisch getestet. Wenn ein Fehler festgestellt wird, erhalten der betroffene Programmierer und die Person, welche das Review durchgeführt hat, automatisch ein Mail.

Powerful tools that are shared company-wide
Die Arbeit und die Qualität der Programmierer werden durch verschiedene interne Tools unterstützt.

Rapid project cycles, developers change projects often, 20% time
Es gibt keine Pläne über mehrere Jahre und die meisten Projekte sind in einer überschaubaren Zeit abgewickelt. Da jeder Entwickler 20 % seiner Zeit zur freien Verfügung hat, entstehen laufend neue Ideen, Features und Projekte.

Peer driven review process, flat management hierarchy
Wenn Unsicherheit besteht, ob die Qualität den Erwartungen entspricht, wird ein Experiment durchgeführt. Dabei erhalten z.B. 1/2 Prozent der Suchenden ein neues Feature (ohne dies zu wissen) und aufgrund der gemessenen Reaktionen wird das weitere Vorgehen bestimmt. Die Hierarchie ist sehr flach und es gibt Manager, welche 40 Mitarbeiter unter sich haben. Es gibt keinen Manager welcher nicht selber programmieren kann. Ausgenommen sind dabei natürlich die Manager ausserhalb der Technik.

Persönliche Schlussbemerkung
Es handelte sich um einen gelungenen Anlass. Persönlich war ich davon fasziniert, wie stark Bernhard Seefeld bereits Teil der Google Kultur ist. Obwohl er noch nicht so lange bei Google ist, konnte ich keinen Unterschied zu Vorträgen über die Entwicklungskultur bei Google feststellen, welche Mitarbeiter gehalten haben, welche fast von Anfang an bei Google sind. Als ehemaliger Qualitätsmanager eines grösseren Softwareunternehmens war ich überrascht, wie konsequent best-practices umgesetzt werden. Als jemand, der sich selber seit 9 Jahren mit Suchmaschinen und deren Algorithmen auseinandersetzt wurde mir klarer, wie Google den hohen Änderungsrhythmus aufrechterhalten kann und warum Google all seine Mitbewerber überholen konnte (s. auch Google Test). Reto Hartinger, welcher diesen Anlass organisierte, hat ein grosses Lob verdient und die beteiligten Google Mitarbeiter haben es verstanden, ihre Firma in einem guten Licht zu präsentieren. Jeder Teilnehmer sollte von den Erkenntnissen profitiert haben.

Kontaktieren Sie

Beat Z'graggen

Experte für online Performancemarketing der ersten Stunde

Jetzt anrufen

+41 (0)41 799 80 99

bz@worldsites-schweiz.ch

Weitere Artikel von Beat Z'graggen

13. March 2024

Thought Leader Marketing: Ads auf LinkedIn vs. SEO

2. March 2024

LinkedIn Ads URL-Trackingparameter: Neu & einfacher

13. February 2024

Demand Generation: Google Ads für mehr Nachfrage