Du bist nicht Google (You Are Not Google)
(blog.bradfieldcs.com)Viele Softwareingenieure handeln bei der Wahl von Technologien nicht rational. Bei der Auswahl neuer Technologien orientieren sie sich oft an Google, Amazon und anderen Big-Tech-Unternehmen, nur weil diese sie verwenden — ohne einen konkreten Bedarf oder eine klare Problemdefinition. MapReduce und Hadoop wurden zum Beispiel für die Verarbeitung sehr großer Datenmengen entwickelt. Wenn Unternehmen ohne ein solches Datenvolumen sie dennoch einführen, handeln sie sich stattdessen unnötige I/O-Kosten und Funktionsverluste ein. Das ist nichts anderes als ein klassischer „Cargo-Cult“ der Technik.
Der Artikel stellt zur Vermeidung dieser unkritischen Nachahmung eine Checkliste namens UNPHAT vor:
Understand – Verstehe das Problem gründlich.
eNumerate – Liste verschiedene Kandidaten auf.
Paper – Lies die zugrunde liegende wissenschaftliche Arbeit oder das Whitepaper.
Historical context – Betrachte den historischen Kontext der Entwicklung.
Advantages – Vergleiche Vor- und Nachteile ausgewogen.
Think – Überlege selbst, ob diese Technologie wirklich zum Problem passt.
Im Artikel werden Technologien wie Cassandra, Kafka und SOA (Service-Oriented Architecture) als Beispiele genannt, die in Situationen unkritisch eingeführt wurden, in denen sie nicht zu den tatsächlichen Anwendungsfällen passten. Kafka wurde etwa für LinkedIn entwickelt, um Millionen von Nachrichten pro Sekunde zu verarbeiten, wird aber mitunter auch in kleinen Unternehmen eingesetzt, die nur einige Dutzend Transaktionen pro Tag haben.
Der Autor betont außerdem, dass selbst Google aufgehört hat, MapReduce zu verwenden, als es dafür nicht mehr geeignet war. Entscheidend ist letztlich nicht die Technologie selbst, sondern dass du genau verstehst, welches Problem du lösen willst, und die passende Technologie dafür auswählst.
Zum Schluss erwähnt der Autor, dass auch Pólya, Hamming und Rich Hickey dieselbe Botschaft immer wieder betont haben. Der Kern ist einfach:
„Denk nach. Und verstehe das echte Problem.“
15 Kommentare
Ich bin zufällig über eine Google-Empfehlung hier gelandet, aber dieser Artikel ist zu stark aus einer Geek-Perspektive geschrieben. Aus geschäftlicher Sicht trifft das überhaupt nicht zu. Warum ist das so?
Für große Tools, die Big Tech verwendet, findet man leicht Fachleute.
Es gibt viele Menschen, die sie lernen, um bei Big Tech einzusteigen, und viele, die sie studieren, weil Big Tech sich dafür entschieden hat. Natürlich ist es deshalb auch leicht, Leute zu finden, die sich damit auskennen, und ebenso einfacher, Erfahrene oder Experten zu rekrutieren. Aber wie wäre es bei einem Tool, das man zum ersten Mal sieht? Es ist nicht so, dass es niemanden gäbe, der sich intensiv damit beschäftigt hat, aber solche Leute zu finden wäre viel schwieriger als Experten für Tools von Big Tech.
Zu den großen Tools, die Big Tech nutzt, gibt es viele Referenzen und Materialien
Zu großen Tools, die viele Menschen verwenden, gibt es reichlich Material zur Problemlösung und viele Google-Suchergebnisse. Die meisten Probleme sind in der Regel Dinge, die andere auch schon erlebt haben, und mit einer einfachen Suche lässt sich das Problem oft leicht einordnen. Bei einem unbekannten Tool ist es dagegen schwer, Referenzen zu finden, und wenn ein Problem auftritt, ist die Wahrscheinlichkeit hoch, dass die Ursachenanalyse erheblich Zeit kostet. Und Zeit ist schließlich Geld. Liegt das Problem wirklich an dem neu eingeführten kleinen Tool? Oder missversteht man eigentlich ein Problem auf einer ganz anderen Seite?
Für Big Tech ist so ein Wechsel eher einfacher. Wegen ihrer enormen Datenverarbeitungsgrößen kann schon ein kleiner I/O-Gewinn ein großer Vorteil sein. Und es gibt viele Leute, die allein deshalb lernen wollen, was Big Tech eingeführt hat. Bei kleinen und mittleren Unternehmen sind geringe I/O-Vorteile aufgrund des relativ kleinen Datenvolumens hingegen kein so großer Gewinn, während die oben genannten Probleme sehr ernst sind. Außerdem gibt es nur wenige, die gezielt Lösungen lernen wollen, die von kleinen und mittleren Unternehmen eingesetzt werden. Deshalb kommt man als Unternehmer eines kleinen oder mittleren Unternehmens oft zu dem Schluss, dass es wirtschaftlicher ist, einfach den Tools von Big Tech zu folgen, statt solche Dinge wie ein Geek bis ins Detail abzuwägen.
Wenn man den Originaltext liest, sieht man, dass er 2017 geschrieben wurde.
Seitdem sind 8 Jahre vergangen, und es ist erstaunlich, dass das alles immer noch zutrifft.
Ich stimme dem oben Gesagten weitgehend zu!
Allerdings denke ich, dass Overengineering in kleineren Unternehmen manchmal auch daher kommt, dass Menschen mit dem Ziel, in große Unternehmen zu gehen, in kleinen Firmen Erfahrungen mit solchen Tools sammeln wollen.
Natürlich findet der Geschäftsführer das wahrscheinlich nicht besonders gut, haha
Ist das nicht zu 80 % der Grund, warum Tools, die auf die Bedürfnisse großer Unternehmen zugeschnitten sind, auch in kleinen Firmen einfach unverändert eingesetzt werden? Eigentlich sollte der CTO das steuern — aber es gibt eben auch Fälle, in denen schon der CTO selbst über einen Wechsel zu einem Großunternehmen nachdenkt.
Wenn es nicht viel zu tun gibt, neigt man dazu, unnötige Dinge zu machen, haha.
Selbst einfache Probleme werden dann unnötig kompliziert gelöst, damit es so aussieht, als hätte man etwas geleistet. Und wenn man es einfach macht, denken viele auch noch, dass es eben einfach gewesen sei … hahaha
Aus Angst davor, etwas Kleines später aufwendig groß umbauen zu müssen, baut man es manchmal von Anfang an zu groß ...
Ich finde, dass der Artikel auch auf K8s anwendbar ist. Er erinnert mich an das Buch „Wie man so programmiert, dass es schwer zu warten ist“. Haha
Letztlich muss man verstehen, welches Problem eine Technologie zu lösen versucht und in welchem Kontext sie entstanden ist. Im Artikel werden dafür zum Beispiel folgende Fälle genannt.
Ich denke, man sollte genau prüfen, ob das Problem, das diese Technologien lösen wollen, und das Problem, das ich lösen will, wirklich zusammenpassen.
Oh, dem stimme ich zu. Das erinnert mich daran, dass ich Studierenden/Junioren beim Mentoring oft geraten habe, die Geschichte der Technologie zu verstehen.
Es scheint erstaunlich viele Menschen zu geben, die gelegentlich vergessen, dass Technologie ein Werkzeug und kein Ziel ist.
Sobald Dinge wie „bei Big Tech validiert“ oder „wird derzeit viel genutzt“ zu den entscheidenden Kriterien bei der Technologiewahl werden, folgen unnötig steigende Kosten ganz von selbst.
In Korea ist der Spring-Cargo-Kult stark ausgeprägt.
Mit Spring ist es einfacher, Personal zu finden...
In Korea ist Spring weniger ein Kult als vielmehr ein Mischwesen aus der Unfähigkeit der Regierung und der Bequemlichkeit der Entwickler..
Dem stimme ich sehr zu. Letztlich ist auch Spring nur ein Werkzeug, um Probleme zu lösen.
Brainstorming, Mindmap, Deep Learning, Forschungs-Work-up-Zeit wird Juli, mein Döstief, mit Langzeit-Zerg ist Wirkung vorhanden