37signals Manifest „Getting Real“ wird nächstes Jahr zehn.
Inzwischen ist mir das kleine Büchlein und seine Ideen in Fleisch und Blut übergegangen. Wenig überraschend, dass es einiges davon auch ins Palasthotel geschafft hat. Anlässlich des ersten „Tellerranddays“ – eine Art firmeninternes Barcamp, das wir einmal im Jahr machen – habe ich mir „Getting Real“ nochmal angesehen, das aus 16 Kapitel und 91 kurzen Essays besteht. Ich werde mir in dieser Artikelreihe jeweils ein Essay anschauen und erklären, wie wir das im Agenturalltag interpretieren. Dabei ist nicht ganz unwichtig zu wissen, dass 37signals eigentlich keine Agentur ist, sondern ein Firma, die Software-as-a-Service-Anwendungen baut, Web-Apps und „Getting Real“ sich auch explizit an Entwickler solcher Anwendungen richtet. Wo einzelne Maximen von „Getting Real“ auf Grund dieses Unterschiedes gar keine Relevanz haben, hab ich sie weggelassen.
Einführung
„Getting Real is a smaller, faster, better way to build software.“
Hier muss ich schon schmunzeln. Damit ist eigentlich schon alles gesagt. Alles andere ergibt sich fast zwingend daraus. Selbst die Begründung. 😀
Die Kernidee von Getting Real ist weniger Software bauen. Das „weniger“ ist dabei gaaaanz wichtig. Es heißt nicht „wenig“, sondern „weniger“. Es ist relativ zu sehen. Relativ zur Menge Software einer normalen Webapp, eines normalen Drupal- oder WordPress-Projektes.
Weil man weniger Software entwickelt, ist man schneller. Und wenn das alleine nicht schon Grund genug ist, besser zu sein, folgt in der Einleitung noch eine weitere Erläuterung.
„Getting Real is staying small and being agile.“
Ein kleines Softwareprojekt ist beweglicher als ein großes. Je größer eine Software wird, desto unbeweglicher wird sie. Und ich möchte noch ergänzen: Ganz egal mit welcher Projektmethode man sich der Software nähert. Große Software ist immer unbeweglicher als kleine. Da helfen auch Scrum und Kanban nix. Diese Grundwahrheit ist der Hauptleitfaden von Getting Real.
Halte Deine Codebasis klein!
Wenn ich das jetzt so lese fällt mir auf, dass das auch einer der Gründe ist, warum wir keinem formalen Projektprozess folgen. Es ist nicht der Prozess, der ein Produkt oder Projekt großartig macht, sondern die Grundidee und die Frage, wieviel von dieser Idee man bis zum Ende retten kann.
