Siebenhundertzwölf

Fast immer wenn bei einer bestehenden Anwendung neue Features gewünscht werden, gibt es Probleme mit der Architektur.

Wenn ich ein neues Projekt aufsetze, habe ich im Allgemeinen vorher ausführlich mit dem Kunden abgestimmt, was denn die neue Software können soll, und wie die Schnittstellen aufgebaut sein sollen.
Ich schreibe das alles ziemlich detailliert in der Spezifikation nieder, die der Kunde dann noch durchliest, und sein OK dazu gibt, bzw. noch Gelegenheit hat, Änderungswünsche zu äußern.
Wenn die Spezifikation erst durchgewunken ist, beginnt die Umsetzung (vorher habe ich vielleicht schon Prototypen erstellt, von denen Screenshots in der Spec abgebildet sind).

Wenn die Spezifikation gut durchdacht war, dann ist die Umsetzung größtenteils straightforward zu bewerkstelligen: Code schreiben, testen, debuggen, dokumentieren, etc.
Bei größeren Projekten kriegt der Kunde zwischendurch mal eine Work-in-Progress Version, wenn er will. Ansonsten time ich das Release so, dass er es rechtzeitig zum vereinbarten Termin bekommt.
Normalerweise ist der Kunde dann erst mal zufrieden (in seltenen Fällen passierte es auch schon, dass ich Kleinigkeiten nachbessern musste).

Nachdem die Software ein oder zwei Jahre im Einsatz war, fällt es Kunden dann manchmal ein, dass sie die eine oder andere Funktionalität auch noch gebrauchen könnten, und ich bekomme einen Auftrag für eine neue Version (da ich mittlerweile ja schon einige Jahre im Geschäft bin, ist dieser Fall deutlich häufiger als ein komplett neues Projekt).
Tja, und da ist es dann häufig der Fall, dass diese neuen Funktionen überhaupt nicht mehr ins bisherige Konzept passen.
Wären diese Erweiterungen von vornherein abzusehen gewesen, hätte ich das natürlich bei der Architektur berücksichtigen können. Aber so passen meine Objekte nicht mehr so recht zu den neuen Anforderungen.

Was macht man dann als Entwickler?
Flicken.

Da werden dann also neue Methoden irgendwie reingepatched. Das ist nicht gerade sauber und elegant. Die Alternative wäre es, das gesamte Projekt noch einmal ganz neu aufzusetzen. Aber das will weder ich (zu langweilig, und ich hänge an meinem alten Code) noch der Kunde (der ja den zusätzlichen Aufwand bezahlen müsste).
Solch reingeflickter Code ist natürlich fehlerträchtiger und die Software läuft tendenziell weniger stabil und robust. Da kommen zusätzliche Abfragen rein, die vorher gar nicht nötig gewesen wären, was die Performance bremst.
Eine oder zwei solche neue Versionen mag eine Software ja aushalten, aber irgendwann ist das ganze nur noch Flickware. Features, die niemand benutzt, weil man sie einfach nicht braucht, oder weil sie zu umständlich zu bedienen sind.

Jede Software hat irgendwo ihr Optimum. Wenn man sie danach noch weiter verbessern will, beginnt die Featuritis, und man sollte sich wirklich überlegen, ob man einen radikalen Schnitt macht, und stattdessen etwas Neues beginnt.

Advertisements

Über breakpoint AKA Anne Nühm

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

11 Antworten zu Siebenhundertzwölf

  1. Leser schreibt:

    Das muss der Kunde dann über den Preis erfahren. Also, je mehr Flickschusterei, desto teurer wird es für den Kunden. Kann man natürlich nicht bei der Beauftragung der Flicken gleich in den Preis für die Modifikationen einpreisen, aber man kann einem Kunden ja doch sicher ungefähr eine Abschätzung geben, in wieweit das die Stabilität und Funktionalität beeinträchtigen könnte, und in wieweit das zu weiteren Folgekosten führen wird.
    Und dann ein Angebot über eine neue Software erstellen, die – weil manche Codebestandteile weiterbenutzt werden können – um einiges günstiger ist, als so ein Projekt eigentlich wäre, aber dafür wieder jahrelang zur vollsten Zufriedenheit läuft.

    Am besten ist es natürlich, dann auch extrem modular zu programmieren, so dass sich die bestehenden Codebestandteile für ein geändertes Konzept wie Bausteine neu zusammen setzen lassen, ohne allzu viel von Null auf neu zu schreiben.

    OK, ich bin kein Programmierer, und das Bild mit dem Bauklötzchenhaus in meinem Kopf passt sicher auch nicht, aber irgendsowas in der Richtung müsste doch möglich sein. ich meine so, dass der Kunde das Gefühl hat, das bessere Produkt zum gleichen oder höchstens einem geringfügig höheren Preis (dafür aber mit dem Mehrwert der besseren Leistung und Stabilität) zu wählen, ohne dass dadurch der Lohn des Entwicklers prekarisiert wird?

    Gefällt mir

    • breakpoint schreibt:

      Selbstverständlich muss der Kunde die Kosten für meinen Aufwand tragen.
      Da ich das recht transparent kommuniziere, ist das auch kein Problem.

      „Am besten ist es natürlich, dann auch extrem modular zu programmieren“
      Das mache ich natürlich weitgehend, aber dieses Konzept hat seine Grenzen.
      Legoteile lassen sich schlecht mit Holzbauklötzen kombinieren.

      Eine neue Anwendung aufzusetzen ist schon wesentlich teurer, als eine bestehende Anwendung zu erweitern.
      Da nehmen die meisten Kunden auch Performanceeinbußen (ist bei meinen Programmen meist eh nicht kritisch) oder kleinere Macken in Kauf.

      Gefällt mir

  2. Athropos schreibt:

    Nennt sich dann Refactoring (etwas, bei dem ich mir gerne denke: „Oh Gott, was hast du da verbrochen?“).

    lG

    PS: passendes captcha: wishy-washy

    Gefällt mir

    • breakpoint schreibt:

      Na, refaktoriert ist mein Code meist ohnehin größtenteils (soweit das eben sinnvoll ist).
      So nutze ich etwa Design Patterns nur selten, da die doch einen recht großen Overhead haben, der sich bei meinen eher kleinen Projekten normalerweise nicht lohnt.

      Hier geht es eher um den ungekehrten Weg, nämlich bestehende Funktionen wieder aufzusplitten, so dass sie je nach Aufruf unterschiedlich reagieren (evtll. Callbacks reinpfriemeln).

      Gefällt mir

  3. idgie13 schreibt:

    Ja – das kenne ich aus leidlicher Erfahrung selber auch zur Genüge.

    Was ich nie verstehen werde:
    Bei z.T. riesigen IT-Projekten ist man (die Herren und Damen Manager) nicht in der Lage sich vorher Gedanken zu machen, was die Software können soll und ändert die Strategie mehrmals während der Entwicklung. Und genau DAS ist IMHO der Hauptgrund für das Scheitern grosser IT-Projekte, es liegt (meist) nicht an unfähigen Entwicklern.

    Ein Architekt muss doch auch wissen, ob er ein Einfamilienhaus, ein Einkaufszentrum, eine Sporthalle oder ein Luftschloss baut …
    Aber bei Software hat der Laie das Gefühl, es muss zu jeder Zeit in jeder Richtung anpassbar sein .. 🙄

    Gefällt mir

    • breakpoint schreibt:

      Stichwort Maut, Gesundheitskarte, .. ich weiß, was du meinst (ein schweizer Beispiel fällt mir gerade nicht ein).
      Tja, da werden die Vorgaben wohl von Managern und Politikern gemacht, die von ihrem Elfenbeinturm aus die Realitäten nicht mehr sehen.
      Insbesondere bei der Gesundheitskarte konnten sich die Verantwortlichen nicht auf gemeinsame Anforderungen einigen.
      Das Hin-und-her darf man den Entwicklern sicherlich nicht anlasten.

      Naja, meine Projekte sind da ja einige Größenordnungen kleiner – und entsprechend einfacher zu überblicken.
      Trotzdem – um in deiner Metapher zu bleiben – wenn das Einfamilienhaus schon sein Richtfest hinter sich hat, ist es gelinde gesagt problematisch, da noch ein Sportschwimmbecken in den Keller zu bauen.

      Gefällt mir

      • idgie13 schreibt:

        An einer meiner vorherigen Arbeitsstellen hatte ich so ein Hick-Hack in einem riesigen Projekt (100 Entwickler, Hard- und Software) miterlebt. Die sind immer noch nicht fertig … 🙄

        Wären die Margen in der Medizintechnik nicht so hoch, wär die Firma schon lange pleite.

        Und da hilft das hochgelobte SCRUM (von dem ich persönlich wenig halte) auch nicht weiter … einen groben Plan sollte man schon haben und nicht alle 2 Tage die Richtung ändern.

        Gefällt mir

        • breakpoint schreibt:

          Um solch ein Kuddelmuddel zu vermeiden, arbeite ich streng nach Spezifikation (die ich allerdings selbst erstellt habe :>).
          Ich fange erst an, ernsthaft an einem Projekt zu arbeiten, nachdem mir der Kunde bestätigt hat, dass er die SW exakt so will, wie in der Spec beschrieben (wenn er sich das später trotzdem noch anders überlegt, dann muss er eben mit Zusatzkosten rechnen).

          Irgendwann habe ich zwar das Agile Manifest unterzeichnet, aber befolge die Prinzipien nur soweit, wie sie mir sinnvoll erscheinen.
          Gerade die geforderte Flexibilität bei Veränderungen ist häufig einfach nicht praxistauglich.

          Gefällt mir

          • Leser schreibt:

            Sicher, dass es so eine gute Idee war, das Agile Manifesto hier zu verlinken, bzw. zu erwähnen? Die Unterzeichner sind alle abrufbar, und die Schnittmenge aus deutschen Namen und weiblichen Vornamen dürfte überschaubar sein, wenn das dann noch mit einer kurzen Recherche (entweder über die mitgelieferte URL oder ähnliches) gebündelt wird, dürfte es auch leicht sein, herauszufinden, welche davon aus Bayern stammen, …

            Oder willst Du Dein Blog beenden?

            Gefällt mir

            • breakpoint schreibt:

              Du kannst ja mal eine Recherche versuchen. B)
              Falls ich damals, vor einigen Jahren, einen Link angegeben habe, ist der vielleicht gar nicht mehr gültig.
              Wer sagt dir, dass ich meinen echten Namen angegeben habe – falls der überhaupt als „deutscher Name“ erkannt wird?
              Vielleicht habe ich zu dieser Zeit noch nicht einmal in Bayern, noch nicht einmal in Deutschland gewohnt?

              Und außerdem ist sowieso ausnahmslos alles, was ich hier schreibe, frei erfunden und erlogen. :>

              Gefällt mir

  4. Pingback: Neunhundertdreiundsechzig | 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