BWL 4 Startups

Wissenswertes für Unternehmer

Was man von professionellen Softwareentwicklern erwarten kann - Teil 1

Stell dir vor, du müsstest dein Leben einer Software anvertrauen, die nachts halb eins von einem 22-Jährigem entwickelt wurde. Unwahrscheinlich? Realität ist, dass dein Leben jeden Tag von einem Softwarefehler beendet werden könnte, z. B. durch Versagen des (softwaregesteuerten) Bremssystems deines Autos oder des Fahrstuhls, in dem du dich gerade befindest. Ebenso könnte ein Rechenfehler dein Flugzeug beim Landevorgang abstürzen lassen.

Ich habe kürzlich eine recht unbekannte Präsentation von Robert C. Martin, der vielen aus der Branche als Uncle Bob bekannt ist, entdeckt, in der er sich ein paar Leuten als neuer CTO vorstellt. Im Gepäck hat er eine Liste von insgesamt 14 allgemeingültigen Forderungen, die er an professionelle Softwareentwicklung, insbesondere an sein Team und jeden Einzelnen stellt. Der Vortrag ist zwar vorrangig an Entwickler gerichtet, allerdings auch jedem zu empfehlen, der mit ihnen zusammenarbeitet.

Wie lauten die 14 Forderungen an seine Entwickler?

They will not ship shit

Sein erste These lautet frei übersetzt: “Der Kunde bekommt keinen Mist vorgesetzt.” und ist die wichtigste Grundregel. Die Software ist frei von Bugs und erfüllt die gesetzten Erwartungen an das Release. Mit der Aussage ist weniger die Auslieferung des fertigen Produkts gemeint, sondern viel mehr, dass das aktuelle Release keine unvollkommenen und halb fertigen Features enthält. Das, was ausgeliefert wird, funktioniert zu 100%.

They will always be ready

Das Entwicklerteam muss jederzeit und innerhalb weniger Stunden dazu in der Lage sein, das aktuelle Release zu deployen und an den Kunden auszuliefern. Vermeiden möchte man, dass einzelne Module erst zusammengesetzt werden oder QA eine Auslieferung wochenlang absegnet. Die Software läuft, soweit die Entwicklung vorangeschritten ist, stabil – die ganze Zeit. Sätze wie “Ich muss da nur noch X und Y an die neue Schnittstelle anpassen.” werden nicht geduldet. Auch hier gilt, dass nicht alle Features fertig zu sein haben, aber die, die es sind, dürfen nicht durch die Weiterentwicklung beeinträchtigt werden.

As soon as code gets checked it, its ready to deploy.

Stable productivity

Die Entwicklungsgeschwindigkeit, d.h., die Implementierung von Features sollte idealerweise während des gesamten Projektverlaufs konstant bleiben. Dies sorgt nicht nur für Sicherheit bei der Planung, sondern gibt Hinweise ob Termine eingehalten werden können. Nun folgt bei vielen Teams dem meist sehr schnellen Projektstart jedoch ein exponentieller Einbruch (rot dargestellt) in der Produktivität. Die Ursache sind oft fehlende Tests und damit schlechter und unwartbarer Code, der die weitere Entwicklung erschwert. Mit jeder zusätzlich ungetesteten Programmzeile erschwere ich die Implementierung neuer Funktionen und mache ein Refactoring unmöglich. Dadurch wird nicht nur das geplante Projektende gefährdet, sondern erschwert die Aufwandsabschätzung weiterer, zum Teil einfacher Features. Die Grafik verdeutlicht diesen Sachverhalt und zeigt warum sauberes Design und Code wichtig für einen geplanten Projektabschluss sind.

Konstante Produktivität

Inexpensive adaptibility

Es ist keine Seltenheit, sondern eher die Regel, dass sich Anforderungen noch während der Entwicklungsphase ändern. Kunden wechseln häufig ihre Meinung und so auch die Anforderungen an die Software. Wenn dieser Fall eintritt, müssen Änderungen kosteneffizient umgesetzt werden können, d. h., Anpassungen an neue Gegebenheiten sollten in kürzester Zeit erfolgen. “Isolate and seperated things that might change from things that do not change.

Beispiel: Wird die MySQL-Datenbank durch eine Postgres-Datenbank getauscht, erfolgt das transparent von der Businesslogik und sollte in wenigen Stunden erledigt sein.

Continuous improvement

Der Code eines Systems sollte nie out-of-date kommen, sondern stets up-to-date bleiben. Alte Versionen einer Programmiersprache, eines Frameworks und einer Library werden durch die jeweils neue abgelöst. Erscheint eine effizientere Bibliothek, Server, etc. erfolgt ein Update, sofern dies sinnvoll ist.

In diesem Zusammenhang erwähnt Uncle Bob die Boy Scout Rule: “Always leave the campground cleaner than you found it.”. Dies heißt soviel wie, ein Programmierer hinterlässt den Quellcode nach dem Editieren stets sauberer als er ihn vorgefunden hat.

Fearless competence

Den Ausgangspunkt hierzu muss man sich wie folgt vorstellen: Ein Entwickler sieht schei* Code, den er jedoch nicht umstrukturiert und verbessert. Das tut er nicht, weil er zu faul ist, sondern weil er ihn beschädigen könnte. Damit fällt die Verantwortung auf ihn zurück und es bekäme sein Code, d.h., seine Baustelle. Hier fordert Uncle Bob jedoch, dass veralteter und unsauberer Code furchtlos und mit viel sorgfalt überarbeitet wird.

Nun lassen sich die Ängste des Programmieres ebenso wenig wegreden, wie einige seiner Thesen einfach umsetzen. Umsetzungsvorschläge greife ich zusammen mit den restlichen Forderungen nach Professionalität in der Softwareentwicklung im zweiten Beitrag zu diesem Thema auf.