Netzgeflüster: Zwei Prinzipien der Softwareentwicklung, die auch im „echten Leben“ was können – KISS und YAGNI

KISS und YAGNI sind mir zwar als Prinzipien der Softwaareentwicklung in Studium und Arbeit begegnet, kommen mir aber umso öfter im „echten Leben“ in den Sinn. Manchmal denke ich, wenn ich die auch abseits des Digitalen so oft beachten würde, wäre mein Leben etwas leichter 🙂 Von solchen Prinzipien gibt es eine Menge und sie sind ein bisschen wie Einhörner. Man weiß nicht so recht wo sie herkommen und es fällt nicht immer leicht an sie zu glauben. Aber die können was.

KISS

KISS ist ein Akronym für Keep it simple. Woher das zweite s kommt, darüber ist man sich uneins. Es existieren Gangarten wie Keep it simply stupid; Keep it simple, stupid oder auch Keep it short and simple. Die Intention ist aber bei allen dieselbe: man soll es so einfach wie möglich halten. Quasi „idiotensicher“ machen und das Rad nicht neu erfinden. Was bedeutet das für die Softwareentwicklung? Code soll wartbar und leicht verständlich sein. Puristen gehen gar dahin, dass Code selbst ohne Kommentare, Dokumentation oder fancy Javadocs nachvollziehbar sein soll. Gelingt das nicht ohne „Hilfsmittel“, dann ist es höchstwahrscheinlich zu kompliziert geschrieben. Was bedeutet das für das Leben abseits des Digitalen? Wenn du dir ein Marmeladenbrot machen willst, würdest du doch auch nicht eine Aufhängung bauen, die das Brot hält, damit du es schmieren kannst? Schließlich kannst du es mit deiner Hand halten oder auf den Tisch oder die Küchentheke oder was auch immer legen, das schon da ist. Genau das. Man muss keine Umwege gehen, sondern soll die einfachsten Mittel nehmen.

Image credit: Ksenia Kudelkina

YAGNI

Das Prinzip YAGNI wiederum steht für You Aren’t Gonna Need It und lässt offenbar nicht ganz soviele Lesarten zu. Übersetzt heißt es in etwa „Du wirst es nicht brauchen“ und sagt eben genau das aus: man solle weglassen, was man nicht braucht. Was bedeutet das für die Softwareentwicklung? Man neigt dazu sich manchmal Code zu schreiben, der nützlich werden könnte. Man sitzt ja gerade an etwas ähnlichem und hat sich einmal eingearbeitet. Vielleicht hat man schon einen Verwendungszweck im Kopf. Und benutzt man den dann später? Vielleicht nicht. Gewartet, gepflegt und abgetestet werden muss er aber wahrscheinlich weiterhin und generiert damit Arbeit. Vielleicht liest den später jemand, um zu verstehen, ob man den noch braucht (oder wie man den denn warten oder abtesten möge) und dann hat der Nächste Arbeit damit. Da ist es: Overengineering, man hat etwas weit vorgedacht, das einfach unnötig ist. Daraus kann Technical Debt entstehen. Code, der mehr Arbeit als Nutzen generiert und eine „Last“ wird. Sinnvoller ist es, das zu schreiben, was man benötigt und eben auch nur das. Was bedeutet das für das Leben abseits des Digitalen? Nehmen wir mal das Shopping-Beispiel: was ich nicht brauche, muss ich nicht kaufen. Dann habe ich mehr Platz und mehr Geld für Dinge, die ich wirklich brauche. Klingt gut, oder? Ist aber nicht nur eine Anleitung zu einer asketischeren Lebensweise. Das lässt sich auf viele Bereiche anwenden bis hin zu: soll ich mir wirklich Gedanken über etwas machen, das vielleicht nie eintritt?

Kanntet ihr die Prinzipien schon? Wendet ihr sie schon an ohne es zu wissen, oder könntet ihr auch noch mehr Pro in KISS und YAGNI werden? Kennt ihr sie vielleicht gar unter einem anderen Namen? Gibt es in eurem Arbeitsumfeld ähnliche Prinzipien? Übrigens ist bei beiden der Ursprung nur so mehr oder weniger klar. Das KISS-Prinzip scheint aus dem Militär zu stammen, während YAGNI wohl ein Pfeiler des Extreme Programming ist.

Netzgeflüster ist eine Kategorie meines Blogs in der ich mich immer zwischen dem 10. und 15. eines jedes Monats Themen aus IT, Forschung, Netzwelt und Internet widme genauso wie Spaß rund um die Arbeit mit Bits und Bytes. 🙂

3 Antworten

  1. Avatar von voidpointer
    voidpointer

    Entscheident ist denke ich MICATCH: Make it cheapest and the customer happy. 😉 Leider verrät es nicht wie das zu erreichen ist. 😉

    Für mich sind Kiss+YAGNI nur zwei Abkürzungen, die mir oft in den Sinn kommen, wenn etwas fertig werden muss. 😉
    Klassische Probleme der Softwareentwicklung sind denke ich überwiegend Komplexitätsprobleme und lassen sich durch Modularisierung oft trivial in einfache Teilaufgaben zerlegen und damit beherrschbar machen. In der Modularisierung steckt also zumindest ein KISS.
    Einfach ist immer gut und wenn es auch noch leicht erweiterbar ist, scheint auch YAGNI eine optimale Vorgehensweise zu sein. Man könnte wohl auch sagen: „Do only what´s needed.“. 😉 😉

    Wenn man aber z.B. an den Schleudersitz im Flugzeug denkt, scheint YAGNI auch mit sehr hohen Kosten einhergehen zu können. Für schwierig Probleme kann es auch keine einfache Lösung geben, erst recht nicht, wenn man die Probleme nicht mal überblickt und blind losläuft und auch loslaufen soll, weil für Anforderungserfassung offenbar kein Budget eingeplant ist und was nicht sein darf auch nicht sein kann … leider schon zu oft erlebt.
    Noch schlechter ist natürlich ein Budget für die Erfassung von Anforderungen zu investieren, die es am Ende nicht gibt. 😉

    Ein bisschen skeptisch sehe ich diese „Abkürzungen“ in der Software-Entwicklung aber schon, weil man sehr viele davon finden kann und sie wenig Zusammenhang bieten. Expertise im entsprechenden Métier ist am einfachsten durch Erfahrung zu gewinnen, denke ich. Expertise bedeutet auch die kurzfristigen und langfristigen Anforderungen zu kennen und abwägen zu können. Kann es passieren, dass man z.B. noch ein Käsebrot oder ggf. sogar N Brote schmieren muss? Schneidet man dann zuerst alle Brote und beschmiert sie mit Margarine bevor man zum Belag übergeht? Wenn man sowas direkt am Anfang bedenken kann, kann das auch viel Aufwand sparen.

    Gut gefällt mir z.B. das SOLID-Prinzip, weil es denke ich bei OOP mit Modularisierung Hand in Hand geht. Auch da setze ich aber nur die Prinzipien soweit um wie es mit geringem Aufwand möglich ist, man könnte also sagen KISS+YAGNI den Vorzug gebe. 😉 Wenn man Libaries für viele andere Entwickler schreibt macht man da natürlich wieder einen anderen Schnitt.

    1. Avatar von Miss Booleana
      Miss Booleana

      Haha, MICATCH musste ich mal googeln. Ich dachte schon da ist was großes an mir vorbei gegangen, aber scheinbar ist es eine Eigenkreation!? 😉 Jaja, die Projektmanager und v.A. die Kunden würde das wohl gerne sehen. Soviel ist klar.

      „Do only what´s needed“ – klingt vernünftig, aber ich bin mir ziemlich sicher, dass sie die Abkürzung DOWN umgehen wollten, weil negativ konnotiert. Haha. Und vllt kam man so zu YAGNI 😉

      Aber helfen die Abkürzungen nicht gerade denjenigen, die die Erfahrung fehlt? Ich sehe da vor meinem inneren Auge Junior Devs vor der geöffneten IDE sitzen und überlegen, ob sie jetzt noch seitenweise das Einlesen einer csv neu erfinden sollen etc.

      1. Avatar von voidpointer
        voidpointer

        Ne ne, das ist nur von mir, aber umschreibt ganz gut die Grundhaltung wie ich sie inbesondere bei kleineren Projekten erlebt habe. Wirklich glücklich kann aber nur der Projektmanager oder der Kunde werden.. 😉
        Wirklich helfen würde es denke ich dem Junior Dev, wenn ihm jemand sagen würde, dass er die und die Library dafür verwenden soll. Zumindest bei 0815 Dingen sollte das immer möglich sein auch wenn es natürlich oft nicht so ist.

Schreibe einen Kommentar zu Miss Booleana Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert