Recht auf benutzerfreundliche Software

Bei den letzten DNUGKöln-Treffen habe ich einen verblüffenden Satz gehört:

Jeder Bürger hat ein streitbares Recht auf benutzerfrendliche Software.

Die Grundlage wird durch die Bildschirmarbeitsverordnung (BildschirmarbV, Dezember 1996) geliefert. Die Liste der Anforderungen an den Bildschirmarbeitsplätzen beinhaltet folegende Punkte:

21.
Bei Entwicklung, Auswahl, Erwerb und Änderung von Software sowie bei der Gestaltung der Tätigkeit an Bildschirmgeräten hat der Arbeitgeber den folgenden Grundsätzen insbesondere im Hinblick auf die Benutzerfreundlichkeit Rechnung zu tragen:
21.1
Die Software muß an die auszuführende Aufgabe angepaßt sein.
21.2
Die Systeme müssen den Benutzern Angaben über die jeweiligen Dialogabläufe unmittelbar oder auf Verlangen machen.
21.3
Die Systeme müssen den Benutzern die Beeinflussung der jeweiligen Dialogabläufe ermöglichen sowie eventuelle Fehler bei der Handhabung beschreiben und deren Beseitigung mit begrenztem Arbeitsaufwand erlauben.
21.4
Die Software muß entsprechend den Kenntnissen und Erfahrungen der Benutzer im Hinblick auf die auszuführende Aufgabe angepaßt werden können.

Das erste, was mir – und ich bin sicher, nicht nur mir – in Sinn gekommen ist, war: wie zum Teufel konnte Windows dieser Verordnung entsprechen?? Ich denke dabei vor allem an Punkt 21.3 …

Am Ende des vorher erwähnten Satzes, gab es allerdings noch eine Bemerkung: “es weißt nur keiner“.

Also jetzt schon.

Off Topic: In dieser Liste gibt es noch einen letzten Punkt:

22.
Ohne Wissen der Benutzer darf keine Vorrichtung zur qualitativen oder quantitativen Kontrolle verwendet werden.

Und jetzt frage ich mich, ob all die Konzerne (Deutsche Bahn, Telekom und wie die alle heißen), die ihren Mitarbeiter ausgespitzelt haben, wirklich dieser Anforderung entsprechen…

40 Jahre – 1600 Kilometer

public static void Main(Events e)
{
    Wenn( e == als Steinbock-Mädchen in einer ungarischen Familie in Rumänien geboren)
    {
       Glücklich aufwachsen
       Ein glücklicher/in einer Diktatur dem Establishment trotzender Teenager sein 
//ohne Diktatur kann man ja nicht so gut trotzen

       /*
       Testlauf für eine Partnerschaft, Akzeptanzkriterien nicht erfüllt, Feature verworfen
       */

       Wenn( e == bei der einzig blutigem Umsturz in Europa in der vordersten Reihe stehen)
       {
            Schätzen lernen, was man hat und was man erkämpft hat.
            Die ersten "Communities" mitgründen
       }
       Wenn(e == !( Fließbandarbeiter von 7 bis 15 Uhr sein wollen ) )
       {
            Eine Uni für Maschinenbau - Fahrichtung Schienenfahrzeuge besuchen
            Coole Sachen erleben // Züge selbst fahren, z.B.
       }
       sonst
       {
           // else gibt es nicht!
       }

       Wenn(e == das beste Model "Ehemann" gefunden && Typeof(e) == Typeof(Ehemann) && e.Land == "Deutschland")
       {
           Alles neu Anfangen // Sprache, Land, Stadt ... Leben
           Wenn(Recht für ein neue Ausbildung durch Zeitarbeit erarbeitet)
           {
                Sich in die Anwendungsentwicklung-Umschulung stürzen, alles lernen, was nur geht.
                Wenn( fertiggelernt )
                      9/11 => IT-Markt absturz // wie auch sonst alle Arbeitsmärkte

               Weitere Sachen lernen // wie. z.B. Lotus Notes
                Wenn(e == Job finden)
                {
                      Noch mehr lernen.
                      Job als Hobby und Hobby als Job definieren.
                      Community beitreten!
                      Noch VIEL mehr lernen.
                }
           }
           Wenn(e == es reicht, den Ehemann nur 3 Tage die Woche zu sehen, da er Consultant || TimeSpan > 6 Jahre)
           {
                 Neuen Job in Köln suchen //Stadt durch zweite Parameter vorgegeben
                 Sleep(7 Wochen) //Wegen ungeplanntem Beinbruch
                 super Job + super Kollegen + tolle Freunde + wunderbare Stadt + geniale Wohnung 
//Wetter könnte besser sein ...

                 Do
                 {
                      continue;

                 } while ( true );
           }
     }
}

Tausende Codezeilen verstehen – aber wie?

Nach 7 Wochen Zwangsurlaub (siehe unten) bin ich wieder back to life: mit einem halbwegs neuen Bein (mit Titaneinlagen und Schlitzschrauben 😉 ), in einer neuen Stadt mit 100%-er Snowcoverage, in einem neuen Job – nach einem Monat Verspätung.

Das letzte Mal, als ich bei einer Firma den Code verstehen musste, ging es um ASP-Classic. Die Abhängigkeiten waren überschaubar, das Debugen ging mit Response.Write-Zeilen ;). Aber wie macht man das heute, wie versteht man den bestehende Code, der in vielen Jahren aus den fleißigen Fingern der Programmierern herausgeflossen ist? Und das im Web, in einer unglaublich flexiblen E-Commerce-Anwendung…

Die Lösung war einfach: mit Unit-Tests ! Ich musste nicht erklärt bekommen haben, WAS der Code tut, nur welche Aufrufe zu welchen Ergebnissen führen. Immer, wenn ich ein Szenario verstanden habe, wurden dafür Tests geschrieben und das Ergebnis besprochen. Der Begriff unit wurde teilweise natürlich ausgedehnt, aber das hat nichts an der Tatsachen geändert, dass am Ende

  1. ich den Code verstanden habe
  2. die meisten analysierten Zeilen durch einen Test abgedeckt wurden
  3. die Diskussionen über den Testnamen dazugeführt haben, dass manch unnötige Zeilen (lese “Szenarien”) entfernt wurden, also der Code besser geworden ist