Direkt zum Hauptbereich

Wie man Software baut: Mach’s einfach!

Mach Dein Projekt in jeder Hinsicht simpel: Verzichte auf eine Datenbank, wenn es eine Text-Datei auch tut. Verzichte auf eine graphische Oberfläche, wenn es eine Kommandozeile tut. Verzichte auf einen Interpreter, wenn es ein Generator tut (oder umgekehrt, wenn der Interpreter die einfachere Lösung ist). Verzichte auf Nebenläufigkeit und Parallelisierung, wenn Geschwindigkeit unproblematisch ist. Verzichte auf Vorwegnahme gemutmaßter Instabilitäten der verwendeten Infrastruktur, wenn es einfache Alternativen gibt, wie das Neustarten einer Anwendung (z.B. in der Nacht). Verzichte auf Eigenlösungen, wenn es bewährte Frameworks oder Bibliotheken gibt. Verzichte auf umfangreiche Fehlerbehandlungen, wenn es einfache Asserts ebenso tun. Ignoriere parallele Dateizugriffe, wenn es kaum konkurrierende Zugriffe gibt und es eine temporäre Zugriffssperre (“Lock”) ebenso tut.

Aber: Verzichte niemals auf eine möglichst einfache, elegante und flexible Umsetzung der geforderten Kernfunktionalität. Stecke dort Deine Arbeit rein! Mach’s einfach.

Warum dieser radikale Ansatz des Verzichts, des Strebens nach dem Naheliegenden, dem Einfachen, dem Schlichten, dem Funktionierenden? Erstens, die Liste dessen, was man so alles tun könnte, ist beliebig erweiterbar. Jeder der Verzichtspunkte stellt eine Anforderung dar, die zu erfüllen jeweils technisch anspruchsvoll ist, das eigentliche Problem, die Kernfunktionalität, aber nicht voran bringt. Diese “Nebenanforderungen” stehen einem beim Lösen des Problems im Weg. Zweitens wird man frühestens mit dem ersten Produkt-Release (oder auch Prototypen) die wirklichen Probleme kennenlernen und verstehen und zu bewerten wissen. Dann kann man darüber nachdenken, ob eine Datenbank, Parallelisierung, Stabilität, Fehlerbehandlung usw. relevant, wichtig und wertschöpfend sind.

Und dann schreibt man, falls notwendig (was meist tatsächlich der Fall ist), das Programm noch einmal neu. Dann implementiert man die geforderte Kernfunktionalität wieder einfach, elegant und flexibel, was dann eine Datenbank, eine graphische Oberfläche, Parallelisierung usw. einschließt. Dann wird alles gut. Dann kommt die Programmevolution in Gang.

Zwei Beispiele:

Wer würde, wollte er oder sie eine neue Programmiersprache entwickeln, mit der IDE anfangen und von der Oberfläche ausgehend die entsprechenden Funktionalitäten entwickeln? Absurd, oder? Java (oder andere Sprachen) beginnen mit Einzelwerkzeugen, wie dem Compiler, einem Dokumentations-Generator, einem Debugger, einer Ausführungsumgebung, einem Build-Tool, einem Editor. Eine IDE bringt diese Werkzeuge unter einer Oberfläche nicht nur zusammen, sondern integriert sie in ein Zusammenspiel, das die einzelnen Werkzeuge transparent macht. Mittlerweile kann man sich Gedanken machen, wie eine IDE nicht nur das Programmieren verändert, sondern sogar eine Programmiersprache prägen könnte (siehe z.B. Greenfoot).

Der Idee des Nachrichtendienstes Twitter ist so einfach, dass jede Informatik-Studentin und jeder Informatik-Student gegen Ende des Studiums einen solchen Nachrichtendienst programmieren kann. Ohne Datenbank. Sogar ohne GUI geht es. Nicht skalierbar. Das ist ein Wochenend-Projekt, so trivial einfach ist die Kernfunktionalität von Twitter. Und dann kann man daraus die Verteiltheit, die Echtzeit-Aspekte, die Skalierbarkeit, Robustheit usw. entwickeln. Kaum anders hat es Twitter gemacht. Die Architektur entstand über Jahre, entwickelte sich fort. Das Twitter von heute ist mit dem Twitter der ersten Jahre gar nicht mehr zu vergleichen. Hätte Twitter versucht, die heutige Twitter-Architektur schon 2006 so zu entwickeln, der Nachrichtendienst wäre vor lauter “Nebenanforderungen” nie erschienen.


Das Einfache, Unkomplizierte, Naheliegende lässt uns anfangen, einen Start finden und strapaziert die kognitiven Ressourcen nicht über. Wer zu viele Entscheidungen treffen muss, wer zu viele Verflechtungen berücksichtigen muss, wer Mühe hat in der Kompliziertheit einer Lösung einen Planungsansatz zu finden, der wird den Start scheuen, prokrastinieren und, ist ein Anfang gemacht, sich immer wieder neu auf den Kern des Vorhabens fokussieren müssen. Das strengt unnötig an.

Beliebte Posts aus diesem Blog

Lidl und der Kassen-Bug

Es gibt Fehler, im Informatiker-Jargon "Bugs", die etwas anrühriges haben. Ich bat den Menschen an der Kasse bei Lidl um einen Moment Geduld und meine Kinder um Ruhe, um nicht den wunderbaren Moment zu verpassen, bei dem es passierte. Der Lidl-Mensch fluchte kurz auf -- und ich war entzückt! "Einen Moment, davon muss ich ein Foto machen!" Und dann machte ich noch eines. Ich bin heute extra für diesen Fehler zu Lidl gepilgert -- ich wollte es mit eigenen Augen sehen. Gestern hat mir ein Student (vielen Dank Herr Breyer) von diesem Fehler in einer EMail berichtet. Ein richtig schöner Fehler, ein Klassiker geradezu. Ein Fehler, den man selten zu Gesicht bekommt, so einer mit Museumswert. Dafür wäre ich sogar noch weiter gereist als bis zum nächsten Lidl. Der Fehler tritt auf, wenn Sie an der Kasse Waren im Wert von 0 Euro (Null Euro) bezahlen. Dann streikt das System. Die kurze Einkaufsliste dazu: Geben Sie zwei Pfandflaschen zurück und Lidl steht mit 50 Cent bei Ihne

Syntax und Semantik

Was ist Syntax, was ist Semantik? Diese zwei Begriffe beschäftigen mich immer wieder, siehe zum Beispiel auch " Uniform Syntax " (23. Feb. 2007). Beide Begriffe spielen eine entscheidende Rolle bei jeder Art von maschinell-verarbeitbarer Sprache. Vom Dritten im Bunde, der Pragmatik, will ich an dieser Stelle ganz absehen. Die Syntax bezieht sich auf die Form und die Struktur von Zeichen in einer Sprache, ohne auf die Bedeutung der verwendeten Zeichen in den Formen und Strukturen einzugehen. Syntaktisch korrekte Ausdrücke werden auch als "wohlgeformt" ( well-formed ) bezeichnet. Die Semantik befasst sich mit der Bedeutung syntaktisch korrekter Zeichenfolgen einer Sprache. Im Zusammenhang mit Programmiersprachen bedeutet Semantik die Beschreibung des Verhaltens, das mit einer Interpretation (Auslegung) eines syntaktisch korrekten Ausdrucks verbunden ist. [Die obigen Begriffserläuterungen sind angelehnt an das Buch von Kenneth Slonneger und Barry L. Kurtz: Formal Syn

Mit Prof. Handke im Gespräch: Vom Workbook zum Inverted Classroom

Aus dem Netz in Handkes Büro Es gibt diese schönen Momente, da führen soziale Medien zu sozialen Begegnungen im echten Leben. Ich twittere im Nachgang zur #BiDiWe16, ein Dialog mit Jürgen Handke ergibt sich, er schickt mir seine Telefonnummer, ich rufe sofort durch, wir verabreden uns. Drei Tage nach der #BiDiWe16 sitze ich bei Handke im Büro, das gleichzeitig sein beachtlich ausgestattetes Aufnahmestudio beherbergt. Es ist Freitagmorgen, 9. September 2016. Jürgen Handke ist mir kein Fremder. Ich habe zwei seiner ICM-Konferenzen besucht, auf der #BiDiWe16 in Berlin hielt er die Keynote. Er hat für seine Lehre Preise erhalten, zuletzt 2015 den Ars Legendi-Preis für exzellente Hochschullehre. Zugegeben, ich hadere mit dem Konzept des Inverted Classroom -- auch Flipped Classroom genannt. Meine Erfahrungen mit der Programmierausbildung von Informatik-Studierenden des 1. und 2. Semesters lassen mich zweifeln. Videos habe ich auch schon produziert, aber vor allem das selbstgesteuerte