Die Kunst des Krieges in der Softwareentwicklung

Wenn Sie in der Softwarebranche arbeiten, haben Sie wahrscheinlich schon vom Designparadigma „ Divide and Conquer “ gehört, das im Grunde darin besteht, ein Problem rekursiv in zwei oder mehr Teilprobleme aufzuteilen ( Divide ), bis diese einfach genug sind, um direkt gelöst zu werden ( erobern ).

Was Sie vielleicht nicht wissen, ist, dass dieses Paradigma aus einer alten politischen Strategie stammt (der Name leitet sich vom lateinischen Sprichwort divide et impera ab), die darauf hindeutet, dass es möglich ist, die Kontrolle über seine Untergebenen oder Untertanen zu behalten, indem man Dissens zwischen ihnen fördert.

Diese Strategie wurde im Laufe der Geschichte von unzähligen Politikern und Militärführern angewendet, wie Julius Cäsar (der sie während der Gallischen Kriege einsetzte, um die militärisch starken Gallier zu besiegen) und Napoleon (der französische Artillerieexperte würde die feindlichen Truppen spalten, damit kein Teil stärker war als seine eigenen Truppen, und dann ihre Kommunikation stören, wodurch die feindlichen Bemühungen, Angriffe zu koordinieren und auszuführen, behindert werden).

Die Kunst des Krieges: Alte Prinzipien für die Entwicklung

Die Teile-und- Herrsche-Regel ist jedoch nicht die einzige politische Strategie, die auf die Softwareentwicklung angewendet werden kann. Obwohl Politik und Kriegsführung wenig mit Softwareentwicklung zu tun haben, müssen Entwickler genau wie Politiker und Generäle Untergebene führen, die Bemühungen zwischen Teams koordinieren, die besten Strategien zur Lösung von Problemen finden und Ressourcen verwalten.

Die Kunst des Krieges ist eine alte militärische Abhandlung, die im fünften Jahrhundert v. Chr. geschrieben und Sun Tzu zugeschrieben wird, einem alten chinesischen Militärstrategen, dessen Theorien einen tiefgreifenden Einfluss sowohl auf die östliche als auch auf die westliche Philosophie hatten.

Trotz seines Alters ist der Text immer noch in den Lehrplänen vieler Militärschulen in Ostasien enthalten und wird an einigen Militärakademien im Westen als empfohlene Lektüre aufgeführt. Der Text ist in 13 Kapitel unterteilt, die jeweils einem anderen Aspekt der Kriegsführung gewidmet sind.

Abgesehen von der Kriegsführung haben die Prinzipien und Lehren von Sun Tzu jedoch praktische Anwendungen in Politik, Wirtschaft, Sport und, ob Sie es glauben oder nicht, in der Softwareentwicklung. Tatsächlich wenden Sie vielleicht nur einige dieser Prinzipien in Ihrer täglichen Routine an, ohne auch nur ihre Ursprünge zu kennen.

Nachfolgend finden Sie eine kurze Liste grundlegender Taktiken und Tipps, die in der Kunst des Krieges erklärt werden. Sie können wahrscheinlich auf Ihren Job in der Softwarebranche oder einer Reihe anderer Branchen angewendet werden.

Zeit ist in jeder Kampagne entscheidend

Kapitel II, Absatz 2

Wenn Sie sich auf echte Kämpfe einlassen und der Sieg lange auf sich warten lässt, werden die Waffen der Männer stumpf und ihr Eifer wird gedämpft.

Dieses Prinzip lässt sich auf die Softwareentwicklung übertragen und beschreibt in der Regel den Zusammenhang zwischen der Länge von Entwicklungszyklen und der Moral der Entwickler.

Wenn eine Gruppe von Entwicklern monatelang an denselben Projekten arbeitet, ohne klare Ziele oder ein Ende in Sicht, können sie frustriert werden und ihre Produktivität kann nachlassen.

Softwareentwicklung ist ein intellektuelles Unterfangen, daher ist Motivation der Hauptantrieb für Produktivität. Jeden Tag zu arbeiten, ohne zu merken, dass Ihre Arbeit echte Ergebnisse bringt, kann sehr demotivierend sein.

Wie in einigen agilen Methoden angegeben, sollte die Entwicklungs-Roadmap in mehrere Ziele und Meilensteine ​​​​unterteilt werden, die das Team möglicherweise in kurzen Zeitrahmen erreichen kann und die ihm ein Gefühl des Fortschritts und der Leistung vermitteln.

Kapitel II, Absatz 18

Lass dein großes Ziel im Krieg also der Sieg sein, nicht langwierige Feldzüge.

Dieser Satz kann auf zwei Arten interpretiert werden:

Erstens kann es als Vorläufer der UNIX-Philosophie angesehen werden: Schreiben Sie Programme, die eine Sache tun und es gut machen . Bei der Entwicklung von Software müssen Sie immer das Hauptziel des Programms, die Hauptfunktion, die es bietet, oder das größte Problem, das es löst, im Auge behalten und eine ordnungsgemäße Implementierung sicherstellen.

Manchmal werden Sie vielleicht inspiriert und denken über eine wirklich coole Funktion nach, die Sie hinzufügen können, aber vergessen Sie nicht, dass Anwendungen mit vielen selten verwendeten Funktionen einen abfälligen Namen haben: Bloatware .

Zweitens kann die Aussage auch als Vorbote für eines der Lean-Software-Entwicklungsprinzipien angesehen werden: So schnell wie möglich liefern .

Je früher Sie Software ohne größere Mängel liefern, desto eher erhalten Sie Feedback vom Kunden und können die Änderungen in die nächste Iteration einfließen lassen.

Wenn Sie andererseits nicht funktionierende Software liefern, entgeht Ihnen wertvolles Feedback, weil Kunden keine Chance haben, sie richtig zu testen. Dies macht die nächste Entwicklungsphase schwieriger oder unmöglich in Situationen, in denen Ihre nächste Iteration vom Kundenfeedback abhängt.

Keine Führung, keine Ergebnisse

Kapitel III, Absatz 11

Jetzt ist der General das Bollwerk des Staates; wenn das Bollwerk an allen Stellen vollständig ist, wird der Staat stark sein; wenn das Bollwerk defekt ist, wird der Staat schwach.

Dieses Zitat beschreibt die Bedeutung der Rolle des Managers in einem Entwicklungsteam: Der Erfolg eines Projekts hängt von der Stärke aller Beteiligten ab, und der Manager ist das Bollwerk des Projekts. Verantwortung beginnt ganz oben.

Auch wenn Entwickler häufig alleine arbeiten (jeder sitzt hinter einem Computer, mit eingeschränkter Kommunikation mit Kollegen), heißt das nicht, dass sie keine gute Führung brauchen. Projektmanager sind dafür verantwortlich, das Team auf Kurs zu halten, eine effektive Kommunikation und Streitbeilegung sicherzustellen, und Führungskräfte definieren natürlich die Prioritäten des Projekts (neben anderen Aufgaben), sodass ihre Rolle nicht unterschätzt werden sollte. Sie sollten auch nicht haftbar gemacht werden, wenn etwas schief geht. Stellen Sie sich vor, was mit einem Militärführer passieren würde, dessen Einheit ihre Pflicht auf dem Schlachtfeld nicht erfüllt?

Ein Team kann großartige Software produzieren, selbst wenn es ein paar schlechte Äpfel in Entwicklungspositionen hat, aber das ist unwahrscheinlich, wenn der Projektmanager der schlechte Apfel ist, egal wie viele Rockstar-Entwickler das Team hat.

Kapitel VI, Absatz 28

Wiederholen Sie nicht die Taktik, die Ihnen einen Sieg eingebracht hat, sondern lassen Sie Ihre Methoden von der unendlichen Vielfalt der Umstände regulieren.

Wenn Sie ein Projekt starten, ist es manchmal verlockend, dieselben Technologien zu verwenden, die wir in früheren erfolgreichen Projekten verwendet haben (dieselbe Programmiersprache, dieselben Bibliotheken, denselben Server usw.). Wenn die Anforderungen der neuen Projekte jedoch nicht genau dieselben sind wie in früheren, ist dies möglicherweise der falsche Ansatz.

In der Programmierung gibt es, wie in den meisten Bereichen, kein Allheilmittel (ein vermeintliches Heilmittel, das alle Krankheiten heilen kann). Es gibt keine einzelne Kombination von Technologien, mit der Sie alle Probleme lösen können. Jede Technologie hat ihre Vor- und Nachteile.

Natürlich kann das Erlernen einer neuen Programmiersprache oder die Verwendung einer unbekannten API anfangs teuer sein, aber langfristig wird die Qualität der Software besser und Sie werden ein besserer Entwickler.

Kapitel XIII, Absatz 27

Daher werden nur der aufgeklärte Herrscher und der weise General die höchste Intelligenz der Armee zu Spionagezwecken einsetzen und dabei große Ergebnisse erzielen. Spione sind ein äußerst wichtiges Element im Krieg, denn von ihnen hängt die Bewegungsfähigkeit einer Armee ab.

Dieser Satz kann als Bedeutung der Verwendung von Überwachungstools und Protokollierungsbibliotheken während der Wartungsphase interpretiert werden.

Auch wenn Kunden das manchmal nicht glauben, endet die Entwicklung nicht, wenn Sie eine stabile und vollständig getestete Version erhalten. Software entwickelt sich ständig weiter, entweder durch Beheben von Fehlern, Hinzufügen neuer Funktionen oder Verbessern der Effizienz.

Und es gibt keine bessere Informationsquelle, um zu wissen, welche Änderungen vorgenommen werden müssen, als Spione zu haben, die die Software in Produktionsumgebungen überwachen und prüfen, welche Funktionen am häufigsten verwendet werden, die häufigsten Fehler und die langwierigsten Vorgänge.

Fehlerberichte, Protokolleinträge und Nutzungsdaten sind grundlegend, um Fehler zu erkennen, Engpässe und andere Probleme zu identifizieren, da es nicht immer möglich ist, dieselben Bedingungen in kontrollierten Testumgebungen zu reproduzieren.

Teamarbeit und Motivation

Kapitel X, Absatz 24

Er, der vorrückt, ohne nach Ruhm zu trachten, Der sich zurückzieht, ohne der Schuld zu entgehen, Er, dessen einziges Ziel es ist, sein Volk zu beschützen und seinem Herrn zu dienen, Der Mann ist ein Juwel des Reiches.

Im Grunde ist dies die alte chinesische Version von „There’s no I in Team“ . Es ist wichtiger, mit anderen zusammenzuarbeiten, als nach persönlichem Vorteil zu streben.

Die Softwareentwicklung ist eine komplexe Aktivität, bei der Entwickler effektiv als Team zusammenarbeiten müssen. Ein guter Entwickler ist nicht derjenige, der die meisten Fehler behebt, die meisten Funktionen implementiert oder Aufgaben vorzeitig abschließt; Ein guter Entwickler ist derjenige, der dem Team hilft, seine Ziele zu erreichen.

Für alles, was Sie getan haben, Anerkennung einzufordern, Ihre Fehler nicht anzuerkennen oder andere dafür verantwortlich zu machen oder sich selbst als Code-Ninja zu bezeichnen, könnte einige unerfahrene Manager täuschen und Ihnen möglicherweise sogar eine Gehaltserhöhung einbringen, aber Sie werden zu einem kontraproduktiven Mitglied Ihres Teams.

Kapitel VII, Absatz 21

Denken Sie nach und überlegen Sie, bevor Sie sich bewegen.

Dieser Satz weist auf die Bedeutung von Teamentwicklungsmeetings hin, wie sie beispielsweise von agilen Methoden vorgeschlagen werden.

Wenn Sie in einem Team arbeiten, ist es wichtig, alle größeren Änderungen zu besprechen, bevor Sie sie implementieren. Es spielt keine Rolle, ob Sie der Teamleiter sind oder die Person mit der größten Erfahrung mit dem Thema, Sie sollten immer mit dem Rest des Teams sprechen oder ihn zumindest informieren.

Denken Sie daran, dass andere Entwickler Ihnen Einblicke in unbekannte Teile der Software geben könnten. Dies bedeutet, dass sie schneller als erwartet mit der Umsetzung der Änderungen beginnen könnten, da sie sich der Auswirkungen dieser Änderungen vollständig bewusst wären.

Kapitel X, Absatz 25

Betrachte deine Soldaten als deine Kinder, und sie werden dir in die tiefsten Täler folgen; Betrachte sie als deine eigenen geliebten Söhne, und sie werden dir bis in den Tod beistehen.

Dieses Zitat weist auf die Bedeutung von Motivation hin, einem Managementprinzip, das von Managern und Teamleitern manchmal vergessen wird. Motivierte Entwickler schreiben besseren Code, arbeiten schneller, begehen weniger Fehler und sind eher bereit, Überstunden zu investieren.

Motivation muss von Managern erzeugt werden, indem sie echtes Interesse an ihren Untergebenen zeigen, ihnen zuhören, sich um ihre Work-Life-Balance kümmern, ein positives Arbeitsumfeld schaffen und sich um ihre Karrierewege kümmern.

Außerdem sollten Sie Motivation nicht mit Vergütung verwechseln. Jüngste Studien zeigen, dass Geld die meisten Arbeitnehmer nicht motiviert, Geld ist meistens gut, um Mitarbeiter zu gewinnen und zu halten, aber nicht, um sie glücklich über ihre Arbeit zu machen. Daher sollten Gehaltserhöhungen und Beförderungen nicht als Motivationsinstrumente angesehen werden.

In andere Richtungen denken

Kapitel V, Absätze 7, 8 und 9

Es gibt nicht mehr als fünf Musiknoten, aber die Kombinationen dieser fünf lassen mehr Melodien entstehen, als jemals gehört werden können.

Es gibt nicht mehr als fünf Primärfarben, aber in Kombination erzeugen sie mehr Farbtöne, als man je gesehen hat.

Es gibt nicht mehr als fünf Hauptgeschmacksrichtungen, aber Kombinationen davon ergeben mehr Geschmacksrichtungen, als jemals geschmeckt werden können.

Eines der guten Dinge am Programmieren ist, dass die Möglichkeiten endlos sind; Sie können sich grundsätzlich entwickeln, wo immer Sie wollen (zumindest solange kein NP-vollständiges Problem vorliegt).

Mobile Apps, Websites, Spiele, Desktop-Anwendungen … wenn Sie sich mit Programmierung auskennen, sind sie alle in Ihrer Reichweite.

Kapitel III, Absatz 1

In der praktischen Kriegskunst ist es das Beste, das Land des Feindes unversehrt zu nehmen; es zu zerbrechen und zu zerstören ist nicht so gut. So ist es auch besser, eine ganze Armee zu erobern, als sie zu vernichten, ein Regiment, eine Abteilung oder eine Kompanie ganz zu erobern, als sie zu vernichten.

Bei der Arbeit an einem Projekt mit einer großen Codebasis ist es üblich, Module oder Codeabschnitte zu finden, die mit schlechten Praktiken oder unter Verwendung veralteter Bibliotheken implementiert wurden. Obwohl es verlockend sein mag, diesen Code zu löschen (oder zu zerstören), ist es aus mehreren Gründen möglicherweise nicht die beste Idee:

• Legacy-Code ist nicht unbedingt schlecht, manchmal ist es guter Code, der geschrieben wurde, als andere Methoden und Technologien in Betracht gezogen wurden. Aber nur weil es alt ist, heißt das nicht, dass es nicht funktioniert.

• Sie könnten Zeit verlieren, indem Sie Code reparieren, der noch funktioniert, anstatt sich auf das Korrigieren anderer, kritischerer Teile des Codes zu konzentrieren.

• Wenn Sie sich nicht wirklich sicher sind, was Sie tun, bedeutet das Ersetzen eines funktionierenden Codeabschnitts, dass Sie riskieren, neue Fehler oder Bugs einzuführen.

Das bedeutet nicht, dass der Satz „Wenn es nicht kaputt ist, repariere es nicht“ eine gute Strategie ist, sondern dass jedes Projekt Prioritäten, Ziele und Zeitbeschränkungen hat. Wenn Sie also Code finden, der verbessert werden könnte, besprechen Sie ihn mit dem Rest des Teams oder mit dem Projektmanager, um herauszufinden, wann er optimiert werden kann.

Kapitel VIII, Absatz 3

Es gibt Straßen, denen nicht gefolgt werden darf, Armeen, die nicht angegriffen werden dürfen, Städte, die nicht belagert werden dürfen, Stellungen, die nicht angefochten werden dürfen, Befehle des Souveräns, denen nicht gehorcht werden darf.

Auch wenn es nicht direkt gesagt wird, könnten wir dieses Prinzip als Warnung interpretieren, Anti-Patterns zu vermeiden.

Obwohl die Verwendung eines Anti-Musters ein kurzfristiges Problem lösen kann, sollten Sie bedenken, dass es langfristig kontraproduktiv sein wird. Also, egal wie viel Zeit Sie sparen, wie viele Fehler Sie beheben oder wie bequem es für Sie ist, vermeiden Sie sie.

Dennoch gibt es Zeiten, in denen Sie versucht sein könnten, ein Anti-Pattern zu verwenden, um eine dringende Aufgabe zu lösen, und sich selbst versprechen, eine ordnungsgemäße Lösung zu implementieren, wenn Sie mehr Zeit haben, aber denken Sie an eines von Murphys Gesetzen: Alle schnellen Lösungen werden zu dauerhaften Änderungen.

Fazit

Obwohl die Entwicklung von Software etwas anderes ist, als Soldaten im Krieg zu kommandieren oder ein Land zu führen, müssen sie Probleme lösen, die Teamarbeit, gute Führung, Effizienz und langfristige Lösungen erfordern.

Die Kunst des Krieges ist jedoch nicht das einzige Buch, das Prinzipien enthält, die auf die Softwareentwicklung angewendet werden können. Niccolo Machiavellis Der Prinz ist ein Beispiel.

Tatsächlich ist hier eine Liste von Zitaten von Machiavelli, die immer noch relevant sind. Versuchen Sie zu erraten, welches die entsprechenden Prinzipien in der Welt der Softwareentwicklung sind.

1. Der Löwe kann sich nicht vor Fallen schützen, und der Fuchs kann sich nicht vor Wölfen schützen. Man muss also ein Fuchs sein, um Fallen zu erkennen, und ein Löwe, um Wölfe zu erschrecken.
2. Versuchen Sie niemals, mit Gewalt zu gewinnen, was durch Täuschung gewonnen werden kann.
3. Nie wurde etwas Großes ohne Gefahr erreicht.
4. Wer dauerhaften Erfolg will, muss sein Verhalten mit der Zeit ändern.
5. Männer beurteilen im Allgemeinen mehr nach dem Schein als nach der Realität. Alle Männer haben Augen, aber nur wenige haben die Gabe der Durchdringung.
6. Wer gehorchen will, muss befehlen können.
7. Weisheit besteht darin, die Natur von Schwierigkeiten zu unterscheiden und das kleinere Übel zu wählen.
8. Krieg lässt sich nicht vermeiden; es kann nur zum Vorteil Ihres Feindes verschoben werden.
9. Die Natur erschafft wenige mutige Männer; Industrie und Ausbildung machen viele.