Thursday, March 9, 2017

An inkrement a day keeps the doctor away

Kuenstler wie Ed Atkins liefern kein finales Werk mehr, eher Snapshots einer ohnehin ueber Animation verworfenen Wirklichkeit (z.B. im MMK Frankfurt). So wenig Entwickler Teams den Gewerken beim Hausbau gleichen, sondern vielmehr einer hoffentlich gut ausgeruesteten und erfahren Expeditionsmannschaft, so wenig laesst sich die Vorstellung von "fertig" auf Softwareentwicklung anwenden. Software befindet sich in einer Dauerschleife der Herstellung kleinster Inkremente, die einen direkten funktionalen Nutzen (ein neues Feature) fuer den Kunden haben oder ueber indirekte, nicht-funktionale Verbesserungen die Nutzung aller Feature verbessern (z.B. schnellere Ladezeiten).
Ich behaupte, dass man beim Bauen von Prototypen sehr gut verstehen und lernen kann, wie man durch konsequentes Runterbrechen auf kleinste Einheiten und einfachste Implementierung auch fuer die Zeit nach dem Prototyp in einen Zustand der inkrementellen Dauerlieferung von Nutzen kommen kann.
Mein Versuch zog sich ueber mehrere Wochen, zwei bessere Entwickler als ich, die am Stueck arbeiten, sollten das gleiche Ergebnis in 3 bis 4 Tagen erreichen.

Vorueberlegung zur Arbeitsweise

Ich wollte mehrere Anforderungen miteinander verbinden:
  1. sinnvolle Prinzipien erstellen fuer das schnelle und inkrementelle Arbeiten an einem Prototyp
  2. passende Zeiteinheiten finden fuer das Erstellen von Inkrementen
  3. minimalistisch und Backend-frei arbeiten und *aaS bevorzugt nutzen

Anforderungen an die App

Ich wollte eine statische Seite, die Termine fuer ein Jazzfest listet, abloesen mit einer Seite, die ein nicht-Techniker administrieren kann. Langfristig sollten auch andere Festivals verwaltet werden koennen. Der Prototyp sollte eine Basis schaffen, mit der ich herausfinden kann, wie sich die staendig wechselnden Jazz-Band-Besetzungen im Festivalbetrieb abgebilden und verwalten lassen. Den grossen Kontext will ich kennen, um auf dem Weg dorthin die richtigen Entscheidungen treffen zu koennen. Aehnlich einem Trompetenspieler, der sich beim Spielen einer Tonleiter auf den hoechsten Ton konzentriert, also Luft und Spannung fuer diesen Ton aufbaut, um dann in dieser Haltung Ton fuer Ton zu spielen.
Was soll der Prototyp koennen?
  1. Ich kann einen Zeitplan mit Band, Uhrzeit, Datum und Location fuer ein Jazzfest erstellen und administrieren
  2. Ich kann die Daten fuer das Jazzfest ueber eine API auslesen und auf einer Seite fuer Nutzer darstellen
  3. Ich kann die Details zu Band und Location pflegen und anzeigen
  4. Der Admin kann Fotos hochladen und fuer die Seite verfuegbar machen

Schritt 1 - lokale Entwicklung

1. Admin UI mit Nodejs, Express und Mongose
2. Website fuer Nutzer mit Angular 2 und Webpack

Schritt 2 - Integration auf *aas Loesungen

  1. Anbindung der Mongo DB auf mLab
  2. Bereitstellen der Bilder auf Cloudinary.com
  3. Hosten der NodeJs Applikation auf Heroku.com
  4. Hosten der AngularJs Applikation auf einem Digital Ocean Ubuntu Server

Schritt 3 - Deployment

  1. auf Heroku und Digital Ocean
  2. Environments definieren

Die Anforderungen waren schnell formuliert, da es bereits eine Seite gab. Das groessere Ziel, es als Festival Planner fuer verschiedene Anwender verfuegbar zu machen, sollte im Kopf behalten werden, um bei Architektur und Datenmodell nicht zu kurz zu springen.

Regeln und Prizipien fuer das Entwickeln des Prototypen

  • wenn ich keine VM oder Docker Container, die ich sofort (d.h. sofort) verteilbar und lauffaehig habe oder ausreichend Know How dazu habe, erstelle ich das Projekt direkt auf meiner Maschine
  • modelliere die Daten nur mit einem Minimum an Properties, die notwendig sind, um die einfachste Funktionalitaet zu erzeugen. Z.B. hat im ersten Schritt eine Band nur einen Namen, ein Festival nur einen Namen, die Performance eine Zeitspanne, ein Ort nur einen Namen. Weitere Details helfen beim Verstaendnis ueber Struktur und Pflege der Daten nicht.
  • mache keine Datenvalidierung solange nur du selbst und eine Hand voll Leute die Anwendung nutzen
  • keine Layouts, keine Styles - wir wollen vorerst nur nakte Funktionalitaet
  • starte mit statischen Daten und arbeite mit statischen Daten solange es sinnvoll geht
  • implementiere Registrierung und Login erst, wenn du die Seiten oeffentlich machst

Regeln Prinzipien fuer die Organisation der Arbeit

  • konzentriere dich auf die Elemente, die dein Geschaeftsmodell validieren und dem Kunden Mehrwert verschaffen
  • lasse alle (Kano) Basiskriterien weg, von denen du sicher bist, dass du sie leicht liefern kannst (Login, E-Mail, Upload, Social Media integration, etc.)
  • nutze alle Abstraktion, die schon fertig und verfuegbar ist (ORM, OGM, DI,...)
  • verzichte auf eigene Abstraktion solange du mit der Modellierung der Daten und der Logik noch im Fluss bist
  • validiere nicht Daten, sondern dein Datenmodell - jetzt ist der Zeitpunkt, wo du es schnell und einfach aendern kannst
  • suche so frueh wie moeglich den realen Anwendungsfall und den realen Anwender
  • formuliere nur Aufgaben, die in 3 Stunden umsetzbar sind. Ist die Aufgabe nach drei Stunden nicht umsetzbar, verwende solange Zeit, bis du die sie auf eine Groesse geschnitten hast, die in 3 Stunden erreichbar ist
  • So erreichst du Prinzip Nummer 2: liefere jeden Tag mindestens 1 Inkrement
  • Schreibe immer alle Aufgaben auf, die sich als Erweiterung oder Refacturing ergeben. Z.B. Registrierung und Login werden erst notwendig, sobald die Seite live geht. Passwort Reset und Passwort Aenderung koennen noch spaeter hinzugefuegt werden
  • Das Nutzen von *aaS erspart mir eine wachsende Infrastruktur und hilft mir, eine modulare Struktur aufzubauen, in der ich Komponenten oder Services beliebig tauschen kann

Wer sich auf diese Weise an ein Projekt herangetastet hat, wird ohne Muehe mehrfach am Tag ein Deployment machen.