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.

Advertisements

Über breakpoint AKA Anne Nühm

Die Programmierschlampe.
Dieser Beitrag wurde unter Uncategorized abgelegt und mit , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

16 Antworten zu Zwölfhunderteins

  1. ednong schreibt:

    Jaja,
    das waren noch Zeiten, damals.
    Hast du ein neues CSS eingebunden?
    Ressources schreibt man im Deutschen mit 2 „s“ – wahrscheinlich, weil es ursprünglich wohl vom Französischen adaptiert wurde. Immer wieder schön – wie mit Adressen 😉 – da dann im Englischen.

    Ein Handbuch ist nicht nur auf Anfrage Pflicht, sondern kann er gesetzlich verlangen, dein Kunde. Lieferst du das Produkt ohne ein solches aus, solltest du dir im Umkehrschluß lieber schriftlich den Verzicht erklären lassen.

    Die Req Spec ist dein Pflichtenheft?

    Gefällt mir

    • Nee, ich habe hier weder Styles, noch Theme, noch Headerbild geändert.
      Vielleicht hat WP was gemacht?

      Hätte ich Specification mit k schreiben sollen?
      Im Englischen schreibt man Resourcen mit einem s, und so ist das unter Programmierern auch üblich, die den Begriff häufig gebrauchen.
      Ich spreche das übrigens auch mit englischer Aussprache aus, und nicht mit französischer.

      Das Handbuch/Manual/“Hilfe“ bzw. dessen Ausführlichkeit oder sonstige Dokumentation wird mit dem Kunden vereinbart.
      Falls er ausdrücklich nichts davon will, habe ich das schon schriftlich.
      Und was heißt hier „Pflicht“? Andere Länder, andere Sitten, ..

      Ja, ich glaube im Deutschen ist „Pflichtenheft“ oder „Lastenheft“ die Bezeichnung für Req Spec.

      Gefällt mir

  2. Claudius schreibt:

    Ich arbeite ja in einem zeitweise größerem Team an einem relativ großen Softwareprojekt. Da meinte ein Kollege vor einiger Zeit, dass 85% der Zeit für Fehlersuche drauf geht. Zum Teil werden Fehler entdeckt, die schon vor Jahren entstanden sind und in Programmzweigen stecken, die über Jahre nicht genutzt wurden.
    Schon klasse, weil es dann immer superdringend ist…

    Gefällt mir

  3. idgie13 schreibt:

    Für Entwickler am interessantesten sind IMHO mittelgrosse Projekte mit einem kleinem Team (oder allein).
    Am schlimmsten für mich sind grosse Teams (> 20), in dem man dann per SCRUM und ähnlichem Schrott zu Programmiersklaven degradiert werden soll.

    Gefällt mir

    • Claudius schreibt:

      Am allerliebsten sind mir Projekte auf der „grünen Wiese“, die ganz am Anfang stehen und wo noch über die Strategie diskutiert wird und Prototypen gebaut und verglichen werden.
      Leider bisher nur einmal erlebt…
      Scrum halte ich für BWLler-gesteuerte Zeit- und Motivationsverbrennung.

      Gefällt mir

      • idgie13 schreibt:

        Meine meisten Projekte haben bei 0 angefangen – die finde ich auch am spannendsten. Am tollsten ist, wenn man wirklich alles von A-Z machen und (mit-)entscheiden kann.

        Deine Beschreibung von Scrum trifft’s ziemlich genau. Zumal die tollen Scrum-„Master“ :mrgreen: dann ja auch meist Nasen sind, die selber keine Zeile Code zusammenbringen.

        Wenn ich eine Stelle suchen müsste, wäre für mich inzwischen die Aussage „wir entwickeln nach Scrum“ ein Grund, die Stelle nicht anzutreten.

        Gefällt mir

    • An so großen Projekten war ich nie beteiligt – zum Glück. Es ist immer schwierig, sich in den Code anderer Entwickler eindenken zu müssen.
      Die meiste Zeit habe ich alleine vor mich hingewerkelt, und jetzt leite ich mein eher kleines Team. Aber die entwickeln hauptsächlich die Software für unsere Geräte, und was sonst noch damit zusammenhängt. Der Arbeitsanfall hält sich also in Grenzen. Dafür brauchen wir keine 20 Mann.

      Gefällt mir

  4. Pingback: Jobklischees oder Was machst du eigentlich? | Büronymus

  5. Pingback: Vierzehnhunderteins | breakpoint

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s