Die Entwicklung eines Startups gliedert sich in verschiedene Phasen. Die Anforderungen an den CTO können sich in diesen stark unterscheiden. Was in der Startphase richtig und wichtig ist, kann in späteren Phasen nicht mehr ideal oder sogar gefährlich sein. Genau so, wie sich das Unternehmen entwickelt, wächst auch die IT. Im Erkennen dieser Phasen und im Anpassen der Anforderungen liegt die Herausforderung an einen CTO.

Der Erfolg eines Startups hängt in erster Linie von den Menschen ab. Gerade in der Anfangsphase sollte man auf ein kleines Team von überragend guten Leuten setzen. Ein Punkt, der bei Qype schmerzhaft gelernt werden musste, war, das Entwicklungsteam nicht nur aus Freelancern zusammenzusetzen. Am Anfang ist es zwar sehr viel einfacher, gute freie Entwickler zu finden, dies rächt sich aber, wenn man es versäumt, eine gesunde Mischung aufzubauen.

Gute Mitarbeiter zu finden ist schwer. Langfristig sollte man daher versuchen, das eigene Startup interessant zu machen. Zum Beispiel mit eigenen Open-Source-Beiträgen, aktiver Teilnahme an Konferenzen und in User Groups. Vor der Begutachtung des Lebenslaufs eines Entwicklers wird bei Qype nach seinem Namen gegoogelt. Weblogs, Twitter, Mailinglisten und im besten Fall Open-Source-Projekte geben in vielen Fällen einen sehr viel besseren ersten Eindruck ab als der Lebenslauf. Bei Uni-Absolventen ist Enthusiasmus und eine relevante Diplomarbeit viel Wert.

Agile Entwicklungsprinzipien wie Extreme Programming oder Scrum passen perfekt zu einem Startup. In kurzen Iterationen entsteht benutzbare Software, die man relativ schnell direkt beim Kunden ausprobieren kann. Denn nichts ist wichtiger für ein Startup als Feedback.

Zu den agilen Prozessen gehören Prinzipien wie testgetriebene Entwicklung, Continious Integration und automatisierte Deploys. Continious Integration sorgt für das zeitnahe Entdecken von Problemen und ein automatisierter Deploy-Prozess macht das häufige Ausliefern erst möglich. In der Anfangsphase von Qype wurden teilweise mehrmals am Tag neue Versionen aufgesetzt.

Solange man die Basics nicht im Griff hat, macht es keinen Sinn, in fortgeschrittene Themen zu investieren. Eine vernünftige Backup-Strategie ist beispielsweise unerlässlich. Erst vor ein paar Wochen wurde der sechs Jahre alte Service „Journalspace“ komplett eingestellt, weil außer einem Raid-System keine Backups für den Hauptdatenbankserver existierten. Backups müssen aber nicht nur angelegt, sondern auch regelmäßig getestet werden.

In der Anfangsphase ist ein einzelner Server meist ausreichend. Je größer der Cluster wird, desto sinnvoller ist es, moderne Prinzipien wie Virtualisierung oder automatisierte Konfiguration einzusetzen. Bei Qype wurden gute Erfahrung mit „puppet“ [1] gemacht, einem Programm zur zentralisierten und automatisierten Konfiguration, das es ermöglicht, neue Server innerhalb weniger Minuten betriebsbereit zu haben und Konfigurationsänderungen am kompletten Cluster auszuführen.

Entwickler neigen zum Over-Engineering. Sie wollen ihre gesamte Erfahrung aus vergangenen Projekten einsetzen. Dabei wird oft vergessen, dass es weitaus schwieriger ist, überhaupt in die Lage zu kommen, skalieren zu müssen, als die eigentliche Skalierung zu leisten. Solange man noch kein erfolgreiches Produkt hat, womöglich noch alle paar Wochen die Ursprungsidee ändert und anpasst, ist es wenig sinnvoll, Zeit in eine skalierbare Architektur zu stecken. Die wenigsten Startups sind mit der puren Grundidee erfolgreich. Flickr zum Beispiel war am Anfang ein kleines Foto-Sharing-Feature innerhalb eines Online-Games.

Auf der anderen Seite ist es irgendwann nicht mehr möglich, Änderungen oder neue Features zu entwickeln, ohne an die Performance und Skalierung zu denken.

Auch wenn dieser Satz der Management-Theorie kontrovers gesehen werden kann, gilt er auf jeden Fall beim Betrieb von Webapplikationen. Man benötigt so viele Daten wie möglich. Die Grundlage eines jeden erfolgreichen Services ist es, den momentanen Systemzustand detailliert zu kennen. Im akuten Problemfall ist es essenziell zu wissen, wie sich der momentane Zustand vom Normalfall unterscheidet.

Software wie Ganglia [2] oder Munin [3] messen periodisch den Zustand des Systems und zeichnen historische Daten auf. Zusätzlich zu den Basismessungen wie der Systemlast sollte man produktspezifische Erweiterungen bauen: die durchschnittliche Antwortzeit, hochgeladene Fotos pro Minute, lesende und schreibende Datenbankabfragen pro Sekunde und weitere Kriterien. Diese Daten helfen einem nicht nur bei akuten Problemen, sondern sind der Grundstein einer soliden Kapazitätsplanung [4]. Nur mit dem Wissen der historischen Entwicklung dieser Kennzahlen kann man planen, wie viele Server man in einem halben Jahr braucht, wie lange der Speicherplatz noch reicht und wann man Entwicklungszeit in Skalierungsmaßnahmen investieren muss.

Bei Webapplikationen ist Performance einer der wichtigsten Aspekte überhaupt. Zu gern würde man jedes neue Feature und jede Erweiterung der Performance unterordnen, doch leider hat das Produkt-Management meist andere Vorstellungen.

Ähnlich der Skalierung wird das Thema Performance erst in späteren Phasen wirklich wichtig. Je erfolgreicher ein Produkt wird, desto mehr treten Performance-Probleme auf: Was mit 500 Datensätzen noch innerhalb weniger Millisekunden fertig wird, dauert bei 500.000 Datensätzen mehrere Sekunden.
Bei Optimierungen ist es wesentlich sinnvoller, die am häufigsten aufgerufene Seite zu optimieren als eine Seite, die zwar langsam ist, aber am Tag nur wenige Male aufgerufen wird. Für Ruby on Rails gibt es mittlerweile externe Services wie NewRelic [5] oder FiveRuns [6], die einem detaillierte Performance-Daten liefern. Die wichtigsten Regeln zur Optimierung der Frontend-Performance findet man in dem Buch „High Performance Web Sites“ von Steve Souders.

Es wird zu Fehlern kommen, das kann keine noch so gute Vorbereitung verhindern. Neben einer offenen Kommunikationspolitik ist es wichtig, aus Fehlern zu lernen. Ein Fehler, der auf identische Weise ein zweites Mal vorkommt, ist wesentlich peinlicher und schädigender als beim ersten Mal.

Besonders hilfreich, um wirklich aus Fehlern zu lernen, ist die 5-Whys-Methode [7] zur Ursachenanalyse. Durch das fünfmalige Fragen von „Warum“ kommt man in den meisten Fällen zur Ursache eines Problems und deckt dabei mehrere Schichten des Problems auf. Idealerweise plant man dann Maßnahmen auf jeder dieser Schichten. Die obersten Schichten sind dabei meist kurzfristig („Bringe die Site wieder online“), die untersten langfristig („Neuen Mitarbeitern intensives Test-Driven-Development beibringen“).