Juni 2007 

Ein Termin rückt näher. Steht vor der Tür. Morgen muß ich ausliefern … Scheibenkleister!

Ich habe noch keinen echten Test auf dem Server gefahren, noch nicht alle Funktionen getestet. Das ist auch noch nicht fertig, für jenen Teil habe ich mehr Zeit gebraucht, als ich erwartet hatte. Scheibenkleister!

Ausliefern

Lampenfieber, Panik, zu hohe Ansprüche an die Perfektion? Angst vor dem Versagen, dem eigenen und dem des Programms? Sich selber seinen Ansprüchen ohne Korrektiv ausliefern.
Das ist alles nichts Neues, ist jedem kreativen Handwerker bekannt. So ist das Seelenleben, wenn mein schönes Programm zum ersten Mal auch bei anderen im richtigen Leben laufen muß.

Eigentlich braucht man in der Entwicklung mindestens drei Menschen: einen zum schreiben der Methode, einen zum Testen und noch einen zum Testen, der keine Ahnung hat, was das Programm kann und wie es abläuft. Das bezahlt keiner. Individuallösungen, also Lösungen für die besonderen Bedürfnisse eines Kunden, haben ihre beta-Phase immer beim Kunden. Es gibt keine anderen beta-Tester!

Meine Erfahrung lehrt mich, ich kann noch so viel getestet haben:

• der erste Tester beim Kunden findet sofort etwas, das nicht funktioniert
mir ist das peinlich … die klicken einfach irgendwo und in vollkommen bescheuerter Reihenfolge, gehen nicht mit Tab von Feld zu Feld sondern greifen jedesmal neu zur Maus. Wie soll ich das abfangen?
• meistens ist es eine Frau, eine die keine Lust auf Technik hat
ich habe Ideen für die Gründe, aber das führt in andere Richtungen
• sie stochern sofort im frisch eingebauten, halbgaren Datenbank-Teil
frisch eingebaut oder selber noch nicht zufrieden oder in Erwartung einer Rückmeldung knalle ich [IN THE WORKS] auf das Layout. Das nimmt die Spannung raus

Das ist alles nicht tragisch. Wir, der Kunde und ich, bauen an einer Lösung. Das ist ein iterativer Prozeß. Der Kunde sollte nicht Wochen/Monate warten müssen, um dann mit großem Tamtam das Ergebnis sehen. Das geht in die Hose! Individualsoftware ist nichts für „One more thing“. Die Kunden freuen sich, mit reinwachsen zu können.

Gar nicht testen geht nicht! Alles testen geht auch nicht! Wieviel testen ist genug? Es gibt keine Regel und der Aufwand ist jedesmal ein anderer. Die Gefahr ist, daß die Kunden das Vertrauen verlieren. Das darf nicht passieren. Hilfreiche sind zeitnahe Fehlerbehebungen und Feature-Ergänzungen. Es ist gut, daß Updates mit 4D kein Problem sind, weder für mich noch für den Anwender †.

• Regelmäßige Updates sind vertrauensbildend.
• Sehr überzeugend! Das automatisierte Backup ist seit der 2004 narrensicher.
• Noch besser! 4Dtoday: eine 4D-Produktionsdatenbank stürzt so gut wie nie (91 % der Rückmeldungen) ab *.

Bananen-Software?

ist Software, die an einige zig oder mehr Anwender ausgeliefert wird und erst beim Kunden reift. Darum geht es hier nicht. Ich meine hier nur Projektarbeit und Individualsoftware und die hat nur einen Kunden, auch wenn zig Clients am Server arbeiten. Selbst wenn die Basis immer die gleiche Datenbank ist, ich diese bei mehreren Anwendern einsetze, gibt es bei jedem besondere Anpassungen, eigens zu testende Individualitäten.

Selbst beta-getestete Software, solche mit nur einem Punkt-Update (8.0.6), muß ab und an und unmittelbar nach der Freigabe ein nachgeschobenes Release bekommen (r2). In the wild ist was anderes als ausgesuchte beta-Tester. Käme das häufiger vor, vermutete ich eine falsche Auswahl beta-Tester.

Individual-Software hat keine Chance auf einen beta-Test. Es gibt nur eine Gruppe geeigneter Tester und das sind bereits die Anwender.

Aus Sicht der anderen

Ganz verwunderlich für mich, ist die Rückmeldung vom Kunden. Dort sieht man vieles ganz anders. Was mich die meiste Arbeit kostet, wird nicht entdeckt, und was ich schnell hingeschrieben habe, wird mit viel Lob bedacht.

Nur ich als Programmierer weiß, wo ich Kompromisse eingegangen bin. Entweder wollte der Kunde es so haben oder es gab keine andere Lösung sofort und zum gleichen Preis oder … egal, Termin eingehalten und es läuft. Ich weiß das, der Kunde nicht. Solange es nicht bricht, passiert auch nichts. Da kann ich nachbessern ohne es an die große Glocke zu hängen. Perfekte Software wird nie fertig, 100 % ist nicht erreichbar, geschweige denn zu bezahlen.

By the way: ich liebe Windows. Deren Nutzer sind viel großzügiger mit Fehlern, die mir durchgeflutscht sind, als die Mac-Nutzer.

Also kurz innehalten! Über den Tellerrand gucken. Sich in den Anwender versetzen. Das eigene Hundefutter essen.

Und nun?

Nur Fragen,

• Bin ich wirklich nicht fertig?
• Kann ich wegen dem Popelkram den Termin platzen lassen?
• Kann ich die neue Funktion abhängen und nachliefern?
• Was macht mehr Schaden?

keine Antworten.

Sorry

Alle neuen Funktionen, im Menü oder als Button oder Doppelklick direkt auf dem Layout, rufen die Methode
Sorry ("Funktionsname")
auf. Diese macht nichts anderes, als die Meldung „Leider ist die Funktion «XYZ» noch nicht freigegeben“ anzuzeigen. So bleibt die Oberfläche konsistent und ich ersetze je nach Entwicklungsstand Sorry durch die Freigabe der fertigen Funktion.

Sorry schreibt den Aufruf der nicht freigegebenen Funktion in das Dokument "Fehlermeldungen", das alle von mir abgefangenen Fehler und andere Meldungen aufnimmt. Ich zähle in der Auswertung die Häufigkeit der Aufrufe einer nicht freigegebenen Funktion und setze entsprechend deren Priorität hoch oder werfe sie irgendwann ganz raus, weil niemand sie braucht.