Zwölfhunderteins

Was macht eine Programmierschlampe eigentlich so den ganzen Tag?
Einige meiner Leser sind mit Softwareentwicklung vertraut, für die anderen beschreibe ich weiter unten einmal die Abwicklung eines Softwareprojektes mit Kunden.

Software Engineering ist nicht nur, ein wenig Code zu schreiben. Dazu gehört viel mehr, das damit in Zusammenhang steht.
Das Erstellen von Software ist mehr als ein kreatives Handwerk, und hat auch künstlerische Aspekte. Der Unterschied zur reinen Kunst ist, dass die Ergebnisse auch einen praktischen Nutzen haben.

Zunächst einmal muss ich herausfinden, was genau der Kunde will oder braucht. Das ist manchmal gar nicht so einfach, weil manche Kunden gar nicht so genau wissen, was sie eigentlich wollen, geschweige denn brauchen. Und mit der technischen Machbarkeit muss ich es auch abgleichen.
Sobald ich glaube, zu wissen, was der Kunde erwartet, mache ich auf dieser Grundlage eine Aufwandsabschätzung (was nur mit einiger Erfahrung zuverlässige Werte liefert), schlage einen Puffer drauf, multipliziere mit meinem Stundensatz, runde das Ergebnis großzügig auf, und mache dann so dem Kunden ein Angebot.
Das kann er entweder annehmen, oder ablehnen (nur sehr selten). Eventuelle Änderungen und Zusatzwünsche gehen danach zu seinen Lasten.

In Zusammenarbeit mit dem Kunden schreibe ich die Requirement Specification, in der ich recht ausführlich und mit vielen Einzelheiten beschreibe, was die Software genau machen soll. Dabei visualisiere ich das UI auch durch Screenshots von Prototypen, die ich parallel bereits anlege.
Der Kunde bekommt dann die Spec zum Review. Sobald ich sein OK habe, lege ich richtig los.

Wenn die Spec gut durchdacht ist, ist das eigentliche Programmieren meist recht straightforward zu machen.
Es gehört auch dazu, die Benutzeroberfläche so zu designen, dass sie möglichst intuitiv und ergonomisch benutzbar ist.
Resourcen müssen eingebunden werden.
Ein vernünftiges Errorhandling (das beispielsweise Fehleingaben des Nutzers abfängt) muss implementiert werden, u.a. um Layer-8-Problemen vorzubeugen.
Und alles muss zusammenpassen.

Auf Wunsch des Kunden muss ein Manual verfasst werden, ein Setup erstellt, und, und, und, .. Das ist jedesmal anders. Wenn nur eine Kleinigkeit vergessen wird, schimpft später jeder Nutzer, was das für eine doofe Software ist. Wenn alles passt, sind ausbleibende Bug Reports das höchste Lob.

So sitze ich dann also vor dem Rechner, schreibe Code, teste, debugge, .., dokumentiere, ..
Sofern ich es mit dem Kunden so vereinbart habe, kriegt er auch mal eine Work-in-Progress-Version, zu der er sein Feedback abgeben kann.
Ich arbeite weiter am Projekt, bis es irgendwann abgeschlossen ist, und auch alle meine Tests besteht. Je nach Wünschen des Kunden protokolliere ich die Tests auch ausführlich.

Der Kunde bekommt dann die Software, und in den allermeisten Fällen ist er damit auch zufrieden. Ganz selten muss ich noch kleine Nachbesserungen machen.
Eventuell will er dann nach einiger Zeit eine neue Version mit zusätzlichen Features. Dann geht das Spiel wieder von vorne los.

Und jedesmal ist es faszinierend, wie quasi aus dem Nichts eine neue Software entsteht. Die noch dazu genau das macht, was ich ursprünglich festgelegt und bestimmt habe.

Bei der Softwareentwicklung im Team wird es noch etwas komplizierter. Als Projektmanager muss man koordinieren und synchronisieren, was jeder einzelne Entwickler genau macht, dass alle Einzelpunkte abgedeckt sind, und sie sich nicht in die Quere kommen.
Ohne eine Versionsverwaltung ist das nicht zu handlen.
Insbesondere bei Entwicklungsschritten, die aufeinander aufbauen, ist eine gute Planung unerlässlich.

Wenigstens bin ich da in der glücklichen Situation, mich dabei nicht mit widerspenstigen Kunden herumärgern zu müssen. Allerdings liegt die Verantwortung auch bei mir. Ich möchte ganz gewiss nicht in die Situation kommen, in dem ein von mir verschuldeter Fehler die Firma Geld oder Renommee kostet.