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.
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.