Höhere Mathematik für programmierende Nicht-Akademiker — Heute: Restklassenringe

Grundlagen: Algebraische Strukturen

In der Mathematik basiert alles auf Mengen (Mengenlehre, Schnittmenge, Teilmenge, Vereinigungsmenge und so). Mit den Elementen einer Menge kann man rechnen, d.h. es gibt verschiedene Operationen, die auf der Menge definiert sind.

Aus der Schule kennen wir die Menge der Reellen Zahlen: . Aus der Menge der Reellen Zahlen machen wir eine algebraische Struktur, indem wir ihr Operationen spendieren:

Wendet man eine der Operationen auf ein Element der Menge an, erhält man als Ergebnis wieder ein Element der Menge. und (5 und 6 sind wieder reelle Zahlen). Das nennt man Abgeschlossenheit.

Es gibt verschiedene Arten von algebraischen Strukturen für die jeweils andere Anforderungen gelten. So gibt es beispielsweise Gruppen, Ringe und Körper. Die Unterschiede sind hier erstmal nicht weiter wichtig.

Beispiel

Man kann nicht nur mit den Reellen Zahlen rechnen, sondern beispielsweise auch mit Natürlichen Zahlen (). Das haben wir in der Grundschule gelernt. Wir haben da erfahren, dass “nicht geht”. Später haben wir negative Zahlen kennen gelernt und auf einmal ging das doch. Trotzdem haben uns unsere Lehrer in der Grundschule nicht angelogen. geht wirklich nicht — in der Halbgruppe .

In der Programmierung begegnen uns ständig solche algebraischen Strukturen. ist z.B. auch eine Halbgruppe. Wir können Strings konkatenieren und erhalten wieder Strings (String ist abgeschlossen bezüglich der Operation ) und ist assoziativ: ('a' + 'b') + 'c' = 'a' + ('b' + 'c'). Diese zwei Eigenschaften brauchen wir um Halbgruppe nennen zu können. Außerdem haben wir noch den Leerstring als neutrales Element. 'a' + '' = 'a'. Wir dürfen deshalb sogar einen “Monoid” nennen.

Inverse Elemente

Die Operationen und haben wir oben nicht etwa vergessen. Sie ergeben sich quasi automatisch aus und . ist nämlich nichts anderes als , wobei das inverse Element (bezüglich der Addition) von ist. Das inverse Element bezüglich der Multiplikation wäre , d.h. . Ein Element verknüpft mit seinem inversen ergibt immer das neurale Element (bezüglich der Operation). (additiv inverses) (multiplikativ inverses).

Restklassenringe

Ein Restklassenring ist eine algebraische Struktur, bei der die Menge Restklassen sind. Eine Restklasse ist z.B. . hat genau Elemente, nämlich die Zahlen 0 bis 23. Definiert man noch Addition und Multiplikation, erhält man einen Restklassenring: .

In einem Restklassenring rechnet es sich in etwa so, wie mit Uhrzeiten. Nach 23 Uhr kommt wieder 0 Uhr:

20 (Uhr) + 7 (Stunden) = 27 (Uhr) = 3 (Uhr)

oder mathematisch geschrieben:

Die Modulooperation gibt also an, in welchem Restklassenring du dich befindest. Hier in . Alle “Zahlen” die den selben Rest beim Teilen durch 24 aufweisen sind in der selben Restklasse und damit “gleich”. Also:

Um entsprechend einfacher rechnen zu können, benutzt du die Modulo-Operation und erhältst immer eine Zahl zwischen 0 und 23:

Genau so ist es mit den negativen Zahlen:

0 (Uhr) – 1 (Stunde) = -1 (Uhr) = 23 Uhr

oder mathematisch:

Achtung

Die Modulo-Operation ist nicht in jeder Programmiersprache gleich definiert. Manchmal entspricht sie der oben verwendeten mathematischen Definition, manchmal ist es anders. Will man in Restklassenringen rechnen, muss man das für negative Zahlen bedenken und ggf. Korrekturen vornehmen. http://en.wikipedia.org/wiki/Modulo_operation#Common_pitfalls

Ausblick

Alle Restklassenringe mit einer Primzahl , sind nicht nur Ringe, sondern Körper, d.h. jedes Element hat ein multiplikatives inverses Element. Das ist in der Kryptographie wichtig und wird u.a. bei RSA verwendet.

Hier erstmal zwei Links, die vielleicht ganz interessant sind:

• http://www.tecchannel.de/pc_mobile/notebook/432097/akkus_notebook_lebensdauer_kapazitaet_ladezyklen_lithium_ionen_laufzeit/
• http://de.wikipedia.org/wiki/Lithium-Ionen-Akkumulator#Hinweise_zum_Umgang_mit_Li-Ionen-Akkus

Folgendes meine ich, herausgefunden zu haben:

• Die Ladeelektronik moderner Akkus verhindert das Überladen. Das ist auch sehr wichtig.
• Ebenso verhindert die (Ent-)Ladeelektronik das Tiefentladen. Das heißt, dass der Verbraucher sich lieber vorher abschaltet bzw. die Akkuelektronik die Leistungsabnahme verweigert, bevor der Akku wegen Tiefentladung kaputt geht. Man kann da also fast nichts falsch machen.
• Dieses “fast” bezieht sich auf die Lagerung. Ein Lithium-Akku hat eine Selbstentladungsrate von etwa 1-2% pro Monat. Ein fast leerer Akku kann sich also trotz der intelligentesten Elektronik bei langer Lagerung langsam weiter entladen (d.h. Tiefentladen werden) und damit Schaden nehmen.
• Längere Zeit mit voller Spannung tut dem Akku wohl auch nicht gut (aufgrund irgendwelcher chemischer Degenerierungs-Prozesse, die durch die hohe Spannung begünstigt werden oder so).
• Ähnliche oder andere lebensdauerverringernde Prozesse gibt es wohl auch irgendwie bei niedrigem Akkustand.
• Man lagert einen Lithium-Akku also am besten in etwa halb-vollem Zustand. Ob “halb-voll” 40%, 50%, 60% oder 75% heißt, ist wohl strittig. Ich hab auch schon die Empfehlung gelesen, den Akku leer zu lagern. Diese Empfehlung kann ich aber nicht logisch nachvollziehen.
• Ein weiterer limitierender Faktor ist die Zahl der Ladezyklen. Akkus verkraften nur eine endliche Zahl an Ladezyklen und gehen danach langsam kaputt. Das sind bei Lithium-Akkus so irgendwas zwischen 300 und 800 Zyklen.
• Daraus ergibt sich, dass man je nach Nutzung an nem Akku hoffentlich mindestens ein Jahr Spaß haben sollte und Lebensdauern von mehr als eins-zwei Jahrzehnten utopisch sind.
• Darüber, inwieweit sich halbe Ladezyklen anteilig anrechnen lassen, herrscht wohl irgendwie Uneinigkeit. Auch ist mir nicht ganz klar, ab welchem Ladezustand die unvorteilhaften Prozesse nun wirklich eine Rolle spielen. Ob man jetzt also besser regelmäßig von 50% auf 100%, von 10% auf 100%, von 50% auf 90% oder anders laden soll, ist mir immer noch unklar.
• Mini-Ladezyklen, wie sie z.B. auftreten können, wenn man ein Notebook ständig am Netz betreibt ohne den Akku zu entfernen, sind wohl eher weniger gut.
• Ein weiterer wichtiger Punkt ist die Temperatur. Die ideale Betriebstemperatur liegt wohl zwischen 20 und 40°C. Das ist für Handys ziemlich problemlos, bei Notebooks aber nur selten erreichbar. Auch das ist wohl der Gesundheit der Akkus abträglich. Und natürlich sollte man Akkus (Handys…) nicht nachts im kalten Auto lassen (oder im Sommer im heißen Auto).
• Über Lagertemperatur liest man unterschiedliches. Von Kühlschrank bis Zimmertemperatur.
• Lithium-Akku ist nicht gleich Lithium-Akku. Es können unterschiedliche Materialien verwendet werden und diese können auch noch in unterschiedlicher Qualität verarbeitet sein und von unterschiedlicher Reinheit sind. Und das hat wohl einen bedeutenden Effekt auf die Lebensdauer. Und man sieht das den Akkus nicht an.
• Lithium-Polymer-Akkus haben eine höhere Energiedichte (sind also bei gleicher Kapazität kompakter und eignen sich deshalb besonders für Mobilgeräte. Allerdings verkraften sie etwas weniger Ladezyklen als “normale” Lithium-Ion-Akkus.
• Zudem ist die Leistungsabnahme des Gerätes bzw. die Dimensionierung des verwendeten Akkus entscheidend für die Akkulebensdauer. Unterdimensionierte Akkus altern auch schneller.
• Alles in Allem ist eine gewisse Alterung also gar nicht zu vermeiden. Da Akkus vor dem Kauf u.U. ja auch noch ne Zeit lang gelagert werden und der Alterungsprozess da natürlich auch schon läuft, muss man hoffen, dass man keine allzu alten Akkus kauft. Das Herstellungsdatum steht da nur sehr selten drauf.
• Aufgrund der generellen Alterung macht es also wohl auch wenig Sinn, gleich ein Ersatzakku mit dem Gerät mitzukaufen. Außer vielleicht man benutzt beide Akkus alternierend.

Mein Fazit:

• Ich werde Akkus in halb-vollem Zustand bei Zimmertemperatur lagern und alle zwei, drei Monate den Akku ggf. wieder auf halb-voll bringen.
• Als Kompromisslösung versuche ich Akkus von 25 auf 100% zu laden.
• Bei längerem Netzbetrieb werde ich den Akku entfernen und wie oben beschrieben “lagern”.
• Ich gehe mal davon aus, dass unter realen Bedingungen ein häufig genutzter Akku auch bei guter Pflege nicht viel länger als 3-4 Jahre hält.

So richtig sicher bin ich mir aber irgendwie immer noch nicht, ob das das Richtige ist. Ich könnte natürlich beim jeweiligen Hersteller nachfragen. Ob ich da aber jemanden kriege, der a) Ahnung hat (und nicht nur einen 08-15-geschulten Support-Mitarbeiter) und mir b) auch die ungeschönte Wahrheit erzählen will, ist fraglich. Bis auf weiteres werde ich also wohl meinem gepflegten Halbwissen vertrauen müssen…

“Wie ich sehe, sind Sie mit den Mordfällen Pavlos und Singh befasst. Um Ihnen unnötigen Aufwand zu ersparen, sage ich Ihnen: Ich habe beide getötet. Warum, werden Sie bald erfahren. Allerdings haben Sie ein Problem. Sie können mich nicht verhaften. Sie können mich nicht aufhalten. Denn ich bin tot.”

Vor einiger Zeit habe ich Neuromancer von William Gibson gelesen. Ein bekanntes, viel gelobtes Buch. Und um ehrlich zu sein, war ich enttäuscht. Mal davon abgesehen, dass es manchmal unnötig schwer zu verstehen ist und wirr erscheint (insbesondere am Anfang; wird später besser; so richtig in Fahrt kommt die Geschichte aber nie), ist dort alles, was Technik betrifft… merkwürdig bzw. unrealistisch. Gut, das Buch stammt aus den 80er Jahren, aber dennoch: Mir hat das Buch nicht sonderlich gefallen udn so hab ich die beiden Folgebände gar nicht erst gelesen.

Ganz anders ist es mit dem, was ich jetzt gelsen habe: Daemon und Darknet von Daniel Suarez. Suarez ist Softwareentwickler und das merkt man. Technisch gesehen hat das, was er schreibt, im Großen und Ganzen Hand und Fuß. Und für einen Informatik-Studenten ist es ausgesprochen angenehm, wenn man einen Roman liest, in dem Begriffe wie “IP-Adresse”, “Formatstring-Hack” und “Quellcode” in einem technisch nachvollziehbaren Zusammenhang stehen. Man kann die Bücher auch lesen ohne diese Begriffe zu verstenen. Wenn man sie aber kennt und sieht, dass sie richtig verwendet werden, ist der Roman nochmal so gut. Auch die deutsche Übersetzung macht das nicht kaputt (im Gegensatz zu Fachliteratur lese ich Romane lieber in der deutschen Übersetzung). Es gibt zwar ein paar Stellen, bei denen ich vermute, dass die Übersetzung etwas Merkwürdiges gemacht hat. Das ist eindeutig im Rahmen und tut dem Lesegenuss keinen Abbruch.

Nun, worum gehts? Matthew Sobol ist Chef einer großen Computerspielefirma. Und er ist totsterbenskrank. Er leidet an einer Krankheit, an der er langsam aber sicher stirbt. Kurz nachdem aber die Meldung über seinen Tod durch die Medien geht, geschehen merkwürdige Dinge. Der Daemon, eine verteilte KI, die Sobol auf Basis seiner Computerspiele entwickelt hat, erwacht zum Leben und verfolgt düstere Pläne. Der Daemon wirbt Leute an, begeht Morde und infiltriert Firmennetze. Der Daemon übernimmt die Welt. Und gewisse Leute versuchen das zu verhindern.

Das hört sich ziemlich nach schwarz/weiß-Malerei mit vorhersehbarem Plot an, aber genau das ist es nicht. überhaupt nicht. Diverse Plot Points erzeugen nicht nur Spannung, sondern weichen auch die zu Anfang scheinbar noch herrschende schwarz/weiß- bzw. gut/böse-Trennung auf.

Wie von einem Thriller kaum anders zu erwarten, gehen massenweise Autos kaputt und an Toten mangelt es auch nicht. Und wie von Science-Fiction zu erwarten gibt es immer mal wieder (oder andauernd) Technik die so (noch) nicht existiert. Aber Daemon ist mehr als nur ein Thriller mit starkem Technikanteil. Manche Teile lesen sich wie ein Computerspiel, andere sind in hohem Maße gesellschaftskritisch. Es ist ein intelligenter Roman, der nachdenklich stimmt. Gerade auch, weil er sehr real wirkt. Viel tennt uns nicht von der Welt des Romans — sowohl gesellschaftlich als auch technologisch.

Ich könnte jetzt noch in den Krümeln suchen. Ich könnte erklären, was technisch so nicht funktioniert (z.B. das Portieren einer Computerspiel-Auto-KI auf ein richtiges Auto) und warum die Features des Daemon übertrieben gut sind und kaum Bugs zu haben scheint. Oder ich könnte mich fragen, warum sich ein hochgradig verteiltes System zumindest an einer Stelle (kurz vor Schluss) wie ein zentralisiertes zu verhalten scheint. Ich könnte auch aufzählen, welche Kleinigkeiten man meiner Meinung nach an der Geschichte verbessern könnte. Das würde dem Roman aber nicht gerecht. Im Vergleich zu dem, was andere Romanschreiber fabrizieren, ist das lächerlicher Kleinkram. “Daemon” ist ein guter Roman. Die Geschichte erschafft im wahrsten Sinne des Wortes eine eigene Welt; sie ist spannend, gut erzählt und regt sogar zum Nachdenken an.

Kurz: Ein intelligenter Roman, der mir viel Spaß gemacht hat.

Leider wird Agile Softwareentwicklung oft so verstanden, wie in obigem nicht nur einmal zitiertem Dilbert-Comic. Mein Eindruck ist manchmal, dass das Wort “agil” dazu benutzt wird, dem Nichtvorhandensein einer strukturierten und durchdachten Vorgehensweise einen Namen zu geben. Aber genau das ist agile Softwareentwicklung eben *nicht*. Agile Softwareentwicklung heißt nicht einfach mal drauflos coden und hoffen, dass alles schon irgendwie gut geht.

Letztens hab ich auf heise eine interessante Umfrage gesehen, die genau das zeigt. Zumindest ist das meine Interpretation der Daten.

Nach der Umfrage nutzen 17% gar kein Vorgehensmodell. Dazu kommen die oben genannten Feigenblatt-Agilen und wohl auch ein paar Feigenblatt-Phasenorientierten. Wenn man jetzt auch noch bedenkt, wer die Fragen beantwortet hat (Tester, Entwickler, Manager, …), dann zeigt sich, dass Entwickler deutlich häufiger angeben, keinem Vorgehensmodell zu folgen. Da aber wohl die Entwickler diejenigen sind, die das am besten wissen sollten, vermute ich mal, dass die 26% (Entwickler, die angegeben haben, keinem Vorgehensmodell zu folgen) eher stimmen als die 17% (Durchschnitt über alle Rollen). Da klaffen wohl Anspruch und Wirklichkeit etwas auseinander.

Aber gucken wir mal genauer:

• 27% der “agilen” nutzen ein “eigenes agiles Vorgehensmodell”. Soso…
• 57% nutzen Scrum (weil es grad in Mode ist, das zu behaupten)
• Nur bei 43% der “agilen” Projekten sind Unit-Tests vollständig automatisiert. Knapp 30% haben eine Automatisierungsquote unter 70%. Und nennen sich dabei “agil”.

Die genannte Statistik hat sich jetzt auf Tests konzentriert. Ich schätze mal, wenn man da in andere Richtungen fragt, wird man ein ähnliches Bild erhalten: Nicht alle, die behaupten, agile Softwareentwicklung zu betreiben, tun das auch.

Pi mal Daumen schätze ich also mal, ein Drittel der agilen sind nicht wirklich agil. Grob geraten sind wohl 50% phasenorientiert 20% agil und 30% gar nix. Und die Übergänge sind fließend.

Teilweise herrscht auch ein falsches Verständnis: Auf ner Firmenkontaktmesse hab ich auch mal gehört, “agil” sei ja gar nicht neu; früher nannte man das nur iterativ. Aber so ist es natürlich nicht. Die Aussage ist in etwa genauso richtig, wie zu behaupten, dass früher (“prozedural”) Klassen einfach structs oder records geheißen haben. Technisch mag das bis zu einem gewissen Grad stimmen (aber auch nur zum Teil). Jedoch hat sich die Denkweise geändert. Und die Denkweise ist es, die den großen Unterschied macht — sowohl bei der Objektorientierung alsauch bei der agilen Softwareentwicklung.

Nichtsdestotrotz gibt es auch Firmen, die Agilität richtig verstehen und richtig anwenden. Durch die ein oder andere Exkursion hab ich da auch schon welche kennen lernen dürfen. Effektiv ist in den meisten Firmen, die ich bisher kennen gelernt habe, Agilität zumindest ein Thema. Ich denke, man kann also behaupten Agile Softwareentwicklung ist mittlerweile im Mainstream angekommen. Nur heißt das eben noch nicht, dass alle, die sich “agil” nennen, das auch sind.

• Kurzer Realitätsabgleich: In My life as a Code Economist erklärt Eric Sink, warum es sinnvoll sein kann, Bugs im System zu lassen.
• Einen sehr guten Vortrag über die Grundlagen von git gibts hier: http://blip.tv/scott-chacon/git-talk-4113729 Sehr schön ist hier insbesondere die grafische Repräsentation des Repositorys. Die ist wichtig zum Verständnis. Manchmal etwas schnell um dem inhaltlich zu folgen, aber dennoch gut verständlich.
• git for Computer Scientists. Sehr schön! Da wünscht man sich mehr von. Das hier sind ja nur die aller grundlegendsten Dinge.
• Where Did My Architecture Go? ist ein sehr interessanter Vortrag über Softwarearchitektur und wie man auf diese aufpasst.
• Es gibt wieder neue Folgen von Tatort Internet. Also nicht von diesem fragwürdigen Blödsinn auf RTL2 sondern von der Artikel-Serie auf Heise-Security (1 2) Sehr interessant.
• “A good coder writes code that looks like it was easy and straightforward to do” (via)
• Ein paar Lustige Bugs: OpenOffice kann dienstags nicht drucken, E-Mails nur im Umkreis von 500 Meilen (via)

Anderes

• Boa bin ich langsam. Das hier liegt schon seit Ewigkeiten hier um. Ein Punkt oben war noch “Die Delphi-Tage sind ausverkauft” (aus verständlichen Gründen hab ich das vor dem Posten wieder gelöscht; Anachronismen sind nicht sonderlich hilfreich) und WordPress zeigt den 16. August als Erstellungsdatum…

Manchmal passieren Dinge, die uns unerklärlich, ja unglaublich erscheinen. In den letzten paar Tagen, durfte ich an ein paar WLANs rumbasteln und dabei sind diverse solcher Dinge passiert. Und das hat mich dann dazu gebracht, obiges zu meinem Cousin zu sagen. Das will ich mal zum Anlass nehmen und etwas darüber sagen, wie diese unerklärlichen Dinge geschehen.

Aber was ist denn nun passiert?

• Der neue WLAN-Router tut nicht so, wie er soll. Zuerst kommt er ins Internet, aber das WLAN geht nicht. Dann geht WLAN aber kein Internet mehr. Nach ein paar mal neu Booten und Stecker ziehen und wieder reinstecken, tut es wieder.
• Ein anderer WLAN-Router (gleiches Modell) hat laut LED eine Verbindung mit dem Internet. Das Kabel steckt aber nicht im WAN-Port. Netzstecker ziehen und wieder reinstecken und es geht.
• Der selbe WLAN-Router ist per Ping zu erreichen, zeigt bei Eingabe der IP in den Browser keine Konfigurationsoberfläche (Timeout). Ein Reset behebt das Problem.
• Bei selben Gerät ein Admin-Passwort eingerichtet (händisch in beide Edit-Felder eingetragen und gespeichert). Danach nimmt er das Passwort beim Anmelden aber nicht mehr an. Nach einem Reset nochmal versucht (diesmal langsam eingetippt). Selbes Problem. Dann Dummy-Passwort “abc” zum Probieren. Lustigerweise funktioniert das jetzt. Dann das Wunsch-Passwort nicht eingetippt, sondern per Copy’n'Paste jeweils eingefügt. Wieder “Benutzername oder Kennwort falsch”.
• Einen WLAN-AccessPoint als Repeater konfiguriert. Datendurchsatz ca. 40kbps (ja 40kbps bei 802.11n und ner Entfernung von 20cm). Neu Starten hilft diesmal nicht. Zum Testen als AP-Client konfiguriert: selbes Problem. Zum Testen mit anderem AccessPoint verbunden: Klappt problemlos. Wieder zurück zum eigentlich gewünschten AccessPoint: Wieder ewig lahm. Neu Starten hilft immer noch nicht. Einen Tag später nochmal versucht: Klappt auf Anhieb.
• Bei Verwendung des neues Repeaters friert der Rechner ein (Maus und Tastatur reagieren nicht mehr). Der Rechner war per Ethernet-Kabel mit dem Repeater verbunden. Selbst nach Abziehen des Kabels (also der Rechner ist mit dem Repeater nicht mehr verbunden. Beide stehen nur nebeneinander) besteht das Problem weiterhin. Ein bisschen WLAN lässt den Rechner einfrieren.
• Auch ein DSL-Router war mal per Ping zu erreichen und per Browser nicht. Wieder behob ein Steckerziehen das Problem.

Aber wie kann das alles sein? Und was hat das mit Software-Entwicklung zu tun? Ich wage mich mal an eine Erklärung des Unerklärlichen.

Software zu schreiben, die einfach tut, was sie soll, ist leicht. Aber Software zu schreiben, die auch noch dann funktioniert, wenn der User einen Fehler gemacht hat oder sonstige unerwartete Ereignisse passieren, ist schwer. Deshalb werden wir als Entwickler darauf getrimmt, Randfälle zu bedenken.

In meinem diesjährigen Vortrag auf den Delphi-Tagen (Enbugging) hab ich Design by Contract als Denkweise vorgestellt: Man betrachtet Methoden als Verträge. Wenn der Caller seinen Teil der Vereinbarung einhält (Precondition), garantiert der Calee, also die Methode, ihren Teil (Nachbedingung). Darüber hinaus gibt es noch Invarianten, die immer gelten müssen [1].

Es gibt Programmiersprachen (z.B. Eiffel), die DBC von Haus aus unterstützen. Zumindest aber gibt es in den allermeisten Sprachen ein Assert-Statement, mit dem man auch viel in die Richtung machen kann. Viel wichtiger als die konkreten Sprachfeatures finde ich allerdings die zugrundeliegende Denkweise. Durch diese ist man nämlich gezwungen, die ganzen Randfälle und Fehlermöglichkeiten zu bedenken. Die Sprachfeatures helfen dann dabei, diese Denkweise auch wirklich anzuwenden.

Das klingt alles sehr akademisch, ist aber außerordentlich praxisrelevant. Wenn man diese Denkweise nämlich nicht anwendet, bzw. die Sonderfälle nicht bedenkt, kommt es zu den oben beschriebenen Merkwürdigkeiten.

Stecker ziehen und wieder reinstecken bzw. neu starten hilft deshalb, weil das System sich dann wieder in einem validen Zustand befindet. Ganz deutlich sieht man das an dem Beispiel mit dem Router, dessen LED behauptet, er wäre mit dem Internet verbunden, obwohl das WAN-Kabel gar nicht angeschlossen war. Das sind inkonsistente Zustände. Die LED behauptet was anderes als das Kabel. Und intern gibt es wahrscheinlich noch ein paar Variablen, von denen die einen behaupten, Internet wäre da und die anderen behaupten das Gegenteil. Das Neustarten behebt das Problem, aber nicht die Ursache. Normalerweise hätte das System gar nicht erst in diesen Zustand kommen sollen.

Es gibt also irgend eine Kombination von Eingaben (Tastendrücke, Signale auf den Leitungen, was weiß ich), die zu diesem invaliden Zustand führt. Das kann etwas ganz Verrücktes sein, wie dreimal Taste 1 drücken, dann Taste 4 gedrückt halten und dabei das Kabel reinstecken. Das für sich genommen erscheint ziemlich unwahrscheinlich, aber meist gibt es viele unterschiedliche solcher Möglichkeiten und Murphys Gesetz zufolge wird einer dieser Fälle auch eintreten.

Jetzt mag man geneigt sein, zu behaupten, dass kein Mensch solche abstrusen Fälle bedenken kann. Und natürlich wird man das auch kaum tun. Das Prinzip, das hier mal wieder hilft, ist das altbekannte Divide and Conquer: Man bedenkt die Problemfälle nicht für das ganze System, sondern getrennt für jedes Modul bzw. jede Methode. Und damit wären wir wieder bei DBC. Diese Denkweise schützt uns davor, all diese überaus nervigen Merkwürdigkeiten in unserer Software zu vermeiden oder zumindest stark zu reduzieren [2].

Es gibt auch Verfahren, die wirklich 100%ig sicher stellen, dass gewisse Zustände nie erreicht werden. Ganze Heerscharen von Informatikern an den Unis beschäftigen sich mit Verfahren zur formalen Verifikation. So etwas ist allerdings sehr aufwändig und skaliert meist nicht auf Code realer Größe. Es gibt hier ein paar Ausnahmen und manches davon wird bei sicherheitskritischen Systemen, bei Autos, Flugzeugen und ähnlichem auch tatsächlich gemacht. Für das typische Informationssystem ist das aber eher weniger geeignet. Hier finde ich robuste Programmierung durch die oben beschriebene Denkweise wichtiger und sinnvoller.

Schauen wir uns jetzt noch kurz an, was ich als konkrete Ursache der obigen Probleme vermute:

• Beim Problem “Ping möglich, HTTP aber nicht” gab es wohl einen Absturz des internen Webservers. Ausgelöst vermutlich durch irgendwelche nicht bedachten Sonderfälle.
• Das mit dem nicht akzeptierten Passwort war ein Problem mit der Passwortlänge. Das Passwort war einfach zu lang. Und statt eine Fehlermeldung auszugeben, wurde das Passwort beim Einspeichern einfach nach 9(?) Zeichen abgeschnitten. Ich hatte sowas schon fast vermutet und deshalb testweise das kopierte Passwort beim Einloggen schrittweise gekürzt. Und irgendwann hats eben geklappt. Dass da wohl jemand vergessen hatte, die Vorbedingung “Passwortlänge < 9 Chars" zu prüfen, brauche ich wohl nicht erst zu erwähnen.
• Das mit dem atemberaubend schlechtem WLAN-Durchsatz kann ich mir immer noch nicht erklären.
• Und bei dem Fall mit dem Einfrieren des Rechners bei WLAN in der Nähe, war wohl der angeschlossene (aber nicht verwendete) WLAN-Stick bzw. dessen Treiber verantwortlich. Der hat irgendwelche Signale gesehen (802.11n statt 802.11g [3]), die er so gar nicht einordnen konnte. Dann hat er nen Fehler produziert, der das System einfrieren lies. Vielleicht nen Deadlock im Treiber.

[1] Es gibt verschiedene Arten von Invarianten, bei denen das “immer” jeweils andere Stellen meint. Für das, was ich hier sagen will, spielen solche Feinheiten aber keine Rolle.
[2] Menschen sind nicht perfekt und damit sind Fehler unausweichlich.
[3] Wobei das WLAN eigentlich im Gemischtbetrieb läuft. Merkwürdig.

“Ist Feature X jetzt endlich fertig?”
“Ja, hab ich gestern eingecheckt.”
“Dann können wir morgen also deployen.”
“Neinnein, da muss noch die QA drüber. Da ist noch nix getestet.”

“Ist Feature Y jetzt endlich fertig?”
“Fast. Zu 90% ist es fertig. Ich muss nur noch…”

Wenn man einmal definiert, was “fertig” bedeutet, kommt es zu weniger Missverständnissen. Mal ganz davon abgesehen, dass man so auch leichter dieses “fast fertig” ausmerzen kann. Entweder ist ein Feature “done” oder eben nicht. Zu 90% fertig bedeutet ja meist, dass noch (weitere) 90% vor einem liegen. Das ist die so genannte 90-90 rule. Und diese ist nur zu oft wahr. Auch, wenn mans vielleicht nicht wahr haben will (mich teilweise auch noch eingeschlossen; ich arbeite daran).

Das ist alles klar und allgemein bekannt. Aber es gibt noch einen anderen Grund für eine DoD: Angenommen man steht unter Zeitdruck (und bei Sprints/Iterationen von zwei Wochen Länge, ist das schnell passiert). Bis Morgen Mittag um 12 muss das Feature fertig sein. Wie schnell ist es da passiert, dass man das nötige Refactoring doch sein lässt und vielleicht auch nur halbherzig testet und dokumentiert — nur um das Feature “fertig” zu kriegen.

Genau genommen ist besagtes Feature aber noch nicht fertig, denn es gibt noch eine gewisse Menge Arbeit, die “für dieses Feature” noch getan werden muss. Und dann ist man auch schon in der nächsten Iteration, hat neue Aufgaben und das Feature bleibt schlecht getestet und das nötige Refactoring wird auch nicht gemacht. Probleme häufen sich auf, es gibt ne Menge Arbeit, die keiner sieht, aber dennoch getan werden muss. Kurz: Man schludert beim Programmieren.

Außerdem neigt man zu “Failure Mode Programming” [1]. Anstatt sauber zu programmieren und zu testen, fixt man nur Bugs und guckt, dass man die Software irgendwie ans Laufen kriegt. Man ist quasi im “Fehler- bzw. Bugfix-Modus” statt im normalen “Programmiermodus”. Fast unbewusst kehrt man zum altbekannten “Code and Fix” zurück, das man doch eigentlich nicht mehr machen wollte. Zeitdruck drängt einen in diese Richtung.

Aber eine klare Definition of Done hilft, sich davor zu schützen. Wenn das Refactoring und eine gewisse Testabdeckung zur DoD dazu gehört, dann ist ein Feature, das nicht sauber entwickelt wurde, dem Tests fehlen und für das noch kein Refactoring gemacht wurde, eben noch nicht fertig. Auch wenn es “im Prinzip läuft”.

Bei der Summerschool “Agile Software Development” hab ich das genau so erlebt. Wir hatten Sprints von etwa zwei Stunden Länge. Und uns fehle eine DoD. Und obwohl ich normalerweise eher einer bin, der zu viel als zu wenig Wert auf sauberen Code legt, bin auch ich in den “Failure Mode” zurück gefallen. Ich denke, wenn wir klar kommuniziert hätten, was “fertig” bzw. “done” heißt, wären wir unterm Strich schneller gewesen. Failure Mode Programming reduziert Codequalität und damit auch die Produktivität.

Kaum hatten wir uns mal in Ruhe hingesetzt und sind den Code Zeile für Zeile durchgegangen, anstatt nur zu debuggen, hatten wir den Fehler auch schon gefunden und dabei auch noch einige Unsauberkeiten ausgebessert. Ein Debugger ist ein tolles Werkzeug und ich verzichte nur sehr ungern darauf, aber letztendlich ist einmal sauber programmieren schneller, als schnell programmieren und dann debuggen.

Das selbe hätte ich zwar auch schon vorher gesagt, aber echter Zeitdruck, macht die Situation anders. Man muss sich das wohl wirklich jedes Mal wieder vor Augen führen. Und eine DoD kann IMHO dabei helfen. An weiteren Maßnahmen arbeite ich noch.

[1] Irgendwo hab ich den Begriff mal gelesen oder zumindest einen ähnlichen. Ich finds gerade nicht. Zur Not ist es eben eine Eigenkreation…

Integration kann man nicht vermeiden. Irgendwann muss man eben mal alles zusammenwerfen und gucken, ob es funktioniert. Je größer die Software und je später die Integration, desto schwieriger wird das Ganze. Deshalb macht man es viel öfter. Nämlich mindestens einmal täglich. Und auf einmal wird alles viel einfacher.

Schön zusammengefasst ist das außerdem in Gall’s Law:

A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.

Integration ist nur ein Beispiel. Das genannte Prinzip steckt in ganz vielen agilen Praktiken und ist außerdem der Grund dafür, dass agile Prozesse hochgradig iterativ sind: Wenn es schwer ist, Software fertig zu kriegen, dann kriegen wir sie eben alle zwei Wochen fertig. Wenn Schätzen schwer ist, dann schätzen wir eben alle zwei Wochen neu, aber dafür kleinere Arbeitspakete. Wenn Testen nervig ist, machen wir es zum Prinzip und schreiben Tests vor dem eigentlichen Code, sodass unser Code unweigerlich testbar wird. Wenn Refactoring fehleranfällig ist, machen wirs doch besser andauernd — immer mal wieder ein bisschen.

Softwareentwicklung ist wie Markklößchensuppe essen: Nicht alle auf einmal, sondern einer nach dem anderen.

Bei Agiler Softwareentwicklung gehen die Meinungen typischerweise stark auseinander. Je nachdem wem man zuhört, ist man geneigt entweder den einen oder den anderen recht zu geben. Beide Argumentationsweisen, beide Softwareentwicklungsphilosophien hören sich, für sich alleine betrachtet, vollkommen vernünftig an. Das hilft natürlich nicht sonderlich weiter, wenn man sich eine eigene Meinung bilden will und so schreibe ich das hier hauptsächlich, um mir selbst hier einigermaßen Klarheit zu verschaffen.

Ursprünglich hatte ich einen vergleichsweise langen Artikel geplant. Ich denke aber, dass mehrere kleinere Artikel eher gelesen werden als ein großer. Außerdem dauert ein großer Artikel immer so lange zu schreiben. Nachdem ich jetzt schon über zwei Monate immer mal wieder an dem Text sitze und immer noch erst etwa ein Drittel steht, habe ich mich nun entschlossen, eine Artikelserie daraus zu machen.

Die Artikelserie spiegelt meine momentanen Gedanken zu dem Thema wider. Ich kann nicht sagen, ob ich bei dieser Meinung, die ich hier mal herausarbeite, bleiben werde. Ich bin einfach selbst mal gespannt, wie ich zur Thematik stehen werde, wenn ich mit der Zeit mehr Einsicht gewinne. Nun gut. Ich hab jedenfalls einiges gelesen und mir meine Gedanken dazu gemacht. Los geht es mit einem geschichtlichen Überblick über die Thematik.

Als man mit dem Programmieren Mitte des letzten Jahrhunderts anfing, machte man sich über solche Dinge keine Gedanken. Man programmierte einfach. Und das auf einem Niveau, das man sich heute gar nicht mehr vorstellen kann. Erkenntnisse wie Kapselung, Abstrakte Datentypen, Strukturierte Programmierung, “goto statement considered harmful” und all das Zeug, das heute so selbstverständlich ist, dass sich keiner mehr darüber Gedanken macht, waren noch nicht bekannt bzw. noch umstrittener Forschungskram.

Nichtsdestotrotz wurden die Programme komplexer und größer. Und weil Murphys Gesetz auch damals schon gegolten hat, endete das Ganze in einer ziemlichen Katastrophe. Genaugenommen in dem, was man die Softwarekrise nennt.

Als Antwort auf die Softwarekrise entstanden Softwaretechnik und Software-Engineering. Auf der einen — technischen — Seite entwickelten sich Programmiersprachen und Tools weiter und die oben genannten Erkenntnisse setzten sich langsam durch. Auf der anderen — organisatorischen — Seite gelangte man zu der Erkenntnis, dass man Software, wie andere komplexe Systeme auch, mit Ingenieursmethoden entwickeln sollte.

Statt dem einfachen “Code and Fix” ging man nun also die Sache systematisch an. Wir spezifizieren unser System zu Tode, bis es sich nicht mehr rühren kann; produzieren Berge von Dokumentation; versuchen jeden Schritt voraus zu planen; und überlegen uns zudem diverse Mechanismen zur Qualitätssicherung. Das funktioniert. Manchmal. Unter gewissen Umständen. Teilweise ziemlich gut sogar. Manchmal funktioniert es auch nicht, aber in jedem Fall ist es enorm aufwändig.

Die Softwarekrise war also immer noch nicht überwunden und es scheiterten immer noch reihenweise große Softwareprojekte — teilweise allerdings aus anderen Gründen. Das Problem war jetzt weniger mangelnde Planung, sondern vielmehr zu viel Planung bzw. die daraus erwachsende Schwerfälligkeit. Typischerweise versuchte man Anforderungen ein für allemal am Anfang eines Projekts aufzunehmen und dann jegliche Änderung an diesen zu minimieren.

Was aber, wenn man die Anforderungen nicht so recht versteht? Oder der Kunde noch gar nicht so genau weiß, was er möchte? Oder sich seine Wünsche mit der Zeit ändern, weil sich die Situation geändert hat? Und diese Bedingungen sind eben keine Einzelfälle.

Softwareentwicklung ist wohl manchmal wirklich etwas anderes, als “andere” Ingenieurswissenschaften. Die Informatik sitzt eh zwischen allen Stühlen. Softwareentwicklung ist kreative Arbeit mit besonderen Anforderungen. Folgendes bringt es eigentlich auf den Punkt:

“When was the last time someone asked the designers of the Empire State building to add ten new floors at the bottom, put a pool on the top, and have all of this done before Monday morning?” (original; via)

Und wegen diesen anderen Voraussetzungen, den sich ändernden, unklaren Anforderungen und weiteren Unterschieden zu traditioneller Ingenieursarbeit, funktionieren plangetriebene Ansätze bei der Softwareentwicklung doch nicht immer so gut, wie erhofft.

Jedenfalls waren einige mit der Situation ziemlich unzufrieden und so entstanden in den 90er Jahren diverse Softwareentwicklungsmethoden, die sich als leichtgewichtige Alternativen zu den schwerfälligen traditionellen Prozessen verstanden. Eine neue Herangehensweise entstand. Im Februar 2001 setzten sich dann 17 Verfechter dieser Ansätze zusammen, um heraus zu finden, ob sie etwas gemeinsam hätten. Und das hatten sie. So entstand der Begriff “Agile Softwareentwicklung” und das Manifesto for Agile Software Development (“Agile Manifesto”).

Im Kern geht es darum, Personen, Kommunikation und Kundenorientierung über Dokumentation und Pläne zu stellen. Das heißt nicht, dass man in der agilen Softwareentwicklung nicht mehr dokumentiert oder plant. Man versucht es nur, auf ein sinnvolles Minimum zu reduzieren.

Es gab jetzt also eine Community mit ähnlichen Ideen, Werten und Prinzipien, sowie eine Hand voll unterschiedlicher aber im Kern ähnlicher Methoden bzw. Prozesse. Von diesen war Extreme Programming (XP) zuerst am erfolgreichsten. Mittlerweile setzt sich aber Scrum immer weiter durch und immer öfter hört man auch von Kanban. Daneben existieren noch weitere wie Crystal, FDD, DSDM und andere. Eine besondere Verbreitung dieser Methoden ist mir bisher aber noch nicht aufgefallen.

Als ich die Ankündigung gelesen hatte, wusste ich sofort, dass ich da mitmachen wollte. Mit agiler Softwareentwicklung wollte ich mich sowieso mal beschäftigen. Außerdem sollte das Ganze auch sehr praxisnah sein. (Wenn man auf ner Uni studiert, sind wirklich praxisnahe Lehrveranstaltungen eher selten.) Und zum Dritten bot sich so mal wieder die Gelegenheit, mit ein paar Firmen in Kontakt zu kommen.

Die Teilnehmerzahl war auf 20 beschränkt, wir waren letztendlich dann aber doch nur 17. Ich hätte gedacht, der Zuspruch wäre größer. Die Veranstaltung war auf jeden Fall klasse.

Bälle, Papierflieger und Lego

Am ersten Tag haben wir Ball gespielt, Papierflieger gebastelt und Legostädte gebaut. Ja, wirklich. Auf spielerische Art haben wir Scrum beigebracht bekommen und eingeübt. Und ich muss sagen, das hat ziemlich gut gepasst. In kurzen Sprints (Iterationen) von wenigen Minuten haben wir so langsam ein Gefühl für agile Denkweise bekommen. Und es hat ne Menge Spaß gemacht. Man hat auch gemerkt, dass die beiden ScrumMaster, die das mit uns gemacht haben, wirklich Ahnung von der Materie haben und mit Spaß bei der Sache waren.

Praktisches

Aber wir haben auch wirklich programmiert und Scrum in kleinen Softwareentwicklungsprojekten eingesetzt. So haben wir einen kleinen Taschenrechner in C# programmiert, eine Android-App geschrieben, eine Webanwendung mit JSF erstellt und gestreamte Börsendaten geparst. Das war alles sehr interessant und so hatte die Veranstaltung noch einen zweiten Lerneffekt: Wir haben einen Einblick in verschiedene Technologien erhalten und diese zumindest ein kleines bisschen angewendet.

Agile Praktiken

Neben dem reinen Vorgehensmodell Scrum haben wir noch Pair-Programming, Planning-Poker und TDD als agile Praktiken kennen gelernt. Anderes wie beispielsweise Continuous Integration wurde nicht behandelt.

Begriffe und Details

Auch manche Begrifflichkeiten und Details wurde nicht erklärt. Chickens and Pigs, Velocity, und anderer Kleinkram.

Letztendlich bedeutet das, dass wir weniger einen 2-wöchigen Scrum-Kurs bekommen haben, sondern mehr eine Veranstaltung bei der Scrum und Agile Softwareentwicklung einen zwar signifikanten, aber dennoch nur einen Teil darstellten.

Aber das war nicht schlecht. Im Gegenteil. Wahrscheinlich haben wir so mehr mitgenommen, als wenn es ein reiner Scrum-Kurs geworden wäre.

Teamarbeit

Teamarbeit ist ein wichtiger Punkt. Agile Softwareentwicklung ist stark teamfokussiert und das hat man gemerkt. Sind die Teams eingespielt, kennen sich die einzelnen Entwickler also untereinander, harmonieren sie miteinander und haben sie auch in etwa gleiche Fähigkeiten, funktioniert Scrum ziemlich gut. Trifft das nicht zu, hakt es an mehreren Ecken und Enden. Es “läuft nicht ganz rund”. Plangetriebene Ansätze verkraften da vermutlich etwas mehr an Unstimmigkeiten.

Man konnte das sehr schön sehen und ich halte das für eine wichtige Erkenntnis und eine gute Erfahrung.

Technik

Die Technik hat leider nicht immer so funktioniert, wie erhofft. SDKs und Application Server funktionierten aufgrund von fehlenden Benutzerrechten nicht und SVN-Repositorys waren auch nicht immer vorhanden. Das war mitunter etwas nervig.

Kontakte

Die Firmen, die das Ganze betreut haben, machen das natürlich nicht ganz uneigennützig. Als Informatik-Student befindet man sich in der vorteilhaften Position, dass einen die Arbeitgeber umwerben, wohingegen in anderen Branchen mehr Bewerber als Stellen existieren. Und da bei der “Summerschool” nicht nur Personaler anwesend waren, sondern wirkliche Entwickler, hatte man die Möglichkeit, diese entsprechend auszufragen.

Wenn man die richtigen Fragen stellt, erhält man so einen Einblick, wie in den jeweiligen Unternehmen Software entwickelt wird. Und, wenn man wie ich, nicht mehr allzu lange zu studieren hat (in anderthalb Jahren bin ich fertig), ist so ein Einblick schon ganz gut. Man will ja schließlich wissen, wo man sich bewerben soll und wo eher nicht.

Meine Meinung zu Scrum und Co.

Nicht alles, was gelobt wird ist gut und nicht alles, was von anderen verteufelt wird ist schlecht. Agile Softwareentwicklung ist ein kontroverses Thema — je nachdem, wen man fragt, erhält man eine andere Antwort. Das alles hilft natürlich nicht unbedingt dabei, sich eine halbwegs klare Meinung zu bilden. Meine Meinung zum Thema ist mittlerweile differenzierter, als dass sie in diesen Artikel noch hineinpassen würde. Ich werde diese also schrittchenweise nachliefern.

Fazit

Im Endeffekt war es eine ausgesprochen gelungene Veranstaltung. Es hat ne Menge Spaß gemacht, wir haben viel gelernt, Erfahrungen gesammelt, Einblicke erhalten und am Schluss eine Teilnahmebescheinigung erhalten, die sich bei Bewerbungen bestimmt gut macht.