Ich bin so etwas, was man “Early Adopter” nennt. Und gleichzeitig empfinde ich mich als “Silent Digital Native”. Das “Silent” habe ich mir dazu gedichtet, weil ich zu der eher zurückhaltend postenden Gruppe gehöre. Das klingt jetzt für einige vielleicht total schwachsinnig, weil meine Tweets ihren Buschfunk flooden, aber diese Leute haben den Schuß nicht gehört. Und das sogar zwei Mal. Nähere Erläuterungen spare ich mir…

Ich trenne mich jetzt endgültig von Facebook und MeinVZ. Auch wenn MeinVZ, Facebook und Google+ wahrscheinlich nicht unterschiedlicher sein können, denke ich, dass Google auch im Social Network Markt annähernd monopolisieren wird. Wenn auch nicht sofort, dann aber innerhalb der kommenden Jahre. Es wird nichts mehr “geliked”. Es wird “gepluseinst”. Das liegt zum Einen an der viel passenderen Fragestellung hinter Google+. Google versucht mit Google+ zu erfahren und verarbeiten was mich interessiert während andere Social Networks vielmehr danach fragen wer ich bin. Was mich interessiert, das möchte ich noch sehen. Wer ich bin, das weiß ich und viele von Euch. Zum Anderen bin ich etwas angekotzt von dieser Spam-Welle von Informationen, die mich nicht interessieren (e.g. Glücksnüsse, etc.). Natürlich wird auch Google+ eine API für Entwickler bekommen und natürlich werden auch da einige Herrschaften “Glücksnüsse” anbauen aber da wird Google die anfallenden Informationen richtiger kanalisieren (siehe “Sparks”) denke ich.

Warum!?

Weil es einfach so ist, wie ich es mir vorstelle. Wir sehen uns beim nächsten Hangout.

Und dann diese Hangouts. Mir fehlen die Worte. Abhängen. Wie geil ist das bitte!? So viele Leute aus meinem Umfeld sind geografisch voneinander getrennt und können nicht einfach mal einen Abend miteinander verbringen. Aber mit Webcam und Headset ist das plötzlich möglich. Wenn mich an meine “World of Warcraft”-Gamer-Zeit zurück erinnere, dann stelle ich fest das es da schon Hangouts gab. Rumhängen in Ironforge und dann über Teamspeak quatschen. Unzählige nette Abende hatte ich so mit Leuten aus Deutschland, Österreich und der Schweiz. Diesen Gedanken formulieren die Hangouts jetzt konsequent zuende in dem sie eine Webcam dazu addieren. Daumen hoch! OK, jetzt werden sicher viele sagen: Ja, aber Skype bla bla bla… Skype, liebe Leute, stürzt bei mir regelmäßig ab seit es den Eigentümer gewechselt hat. Und weil ich mit dem neuen Betreiber auch nicht leben kann, habe ich Skype auf meinem Ubuntu-Rechner direkt von der Platte geputzt. Was soll der Blödsinn auch!? – Es gibt jetzt Hangouts.

Und dann so das Thema Datensicherheit. Ich traue Google durchaus zu fairer mit meinen Daten umzugehen als das Gesichtsbuch. Ich bin so gut wie überzeugt. Super Sache dieses Google+. Wir machen das mit den Fähnchen.

Auf die Gefahr hin, dass Google mich jetzt nicht mehr mag weil ich einfach alle URLs auf perished.de umgebogen habe und blog.perished.de nach vielen Jahren im Äther landet, ist der Umbau jetzt erfolgt. Damit dürft ich auch automatisch aus so 100% der FeedReader rausfliegen, was positiv interpretiert ein neues Publikum bedeutet. So what!

Alternativ könnte ich auch eine RewriteRule anlegen, die blog.perished.de/x/y?z=a auf perished.de/x/y?z=a umleitet. Hat jemand Plan von Rewrites?

Update: Ich hab’s jetzt über eine RewriteRule wie folgt geregelt:

RewriteEngine on
RewriteBase /
RewriteCond %{HTTP_HOST} ^blog.perished.de$ [NC]
RewriteRule ^(.*)$ http://perished.de/%{REQUEST_URI} [R=301,L]


Alle Links bleiben also auch zukünftig wie in der Vergangenheit erhalten.

1. “70 percent of the world’s active business applications are written in COBOL”
Das scheint mir der Ursprung allen Übels zu sein. Dieses Gerücht kann auf eine Untersuchung der Gartner Group zurück geführt werden. Und das nicht gestern sondern im Jahre 2000. Was ein deutliches Zeichen für die Aktualität dieser Behauptung ist. Der Käse wurde vor über 10 Jahren mal gesagt und dann im Internet in die Zukunft gewatscht. Die 70% wurden im Jahre 2000 übrigens an den “lines of code” festgemacht. Was auch hirnrissig ist und womit wir beim nächsten Punkt sind.

2. lines of code
Die Einsatzhäufigkeit einer Programmiersprache wird hin und wieder anhand der aktuell weltweit produktiv laufenden lines of code gemessen. Auch das ist wieder totaler Quatsch. Und natürlich liegt COBOL da richtig weit vorne. Eine nicht-objektorientierte Programmiersprache die fast ausschließlich nur aus dem Befehl MOVE besteht, braucht schon mal ein paar tausend Zeilen um die Fibonacci-Zahlen auszugeben. Das COBOL mit seinen Billionen von produktiven Source-Zeilen beim Zählen der Zeilen einen Blumentopf gewinnt, scheint mir wenig verwunderlich. Es ist jedoch nicht immer so, dass der der viel tut viel Sinnvolles tut.

3. TIOBE Index
Im TIOBE programming community index hat COBOL sich inzwischen auf Platz 41 runter gekämpft. Dieser Index ist eine sortierte Liste der Programmiersprachen und wird aus der Frequenz der Suchanfragen mit dem Namen der Programmiersprache als Keyword zusammen gesetzt. Dafür werden zahlreiche große Suchmaschinen verwendet. Man kann das Ergebnis als eine Liste der Aktivität der Programmiersprachen werten. Und COBOL erreicht dabei gerade mal 0,331 %. Da auch produktiv laufende Anwendungen ein gewisses Volumen an Wartung benötigen und dabei ein Entwickler zur Arbeit geknechtet wird, scheint es auch hier wieder so als sei kaum eine produktive Anwendung in COBOL geschrieben, denn schließlich benutzt heute jeder eine Suchmaschine.

Butter bei die Fische:

TOTALER UNFUG!

COBOL, ist weiter weg von produktiv, als mindestens 40 andere Programmiersprachen auf der Welt. Und wenn es noch Unternehmen gibt, die COBOL produktiv einsetzen ohne einen Gedanken an eine Neuentwicklung ihrer Applikationen zu verschwenden, dann sind diese Unternehmen schon pleite und wissen es noch nicht und in meinen Augen maximal bemitleidenswert.

So… Tacheles Ende…

Wenn ich so nachdenke, dann denke ich zuerst an den Vortrag von Jutta Eckstein, deren Buch „Agile Softwareentwicklung im Großen“ ich schon in meiner Diplomarbeit zitiert haben, und Mirko Novakovic (codecentric AG), der anhand eines Business Cases vorgestellt hat welche Vorteile Agilität uns bringt und wie Agilität das Projektrisiko senkt, wenn das Projekt mal in Zeitverzug geraten sollte. Je länger ich über den Vortrag nachdenke, desto einleuchtender erscheinen mir seine Gedanken. Das Pareto-Prinzip (auch bekannt als 80/20-Prinzip) war auch gestern wieder ein „Allheilmittel“ für den Erfolg agiler Methoden. Mirko Novakovic wies darauf hin, dass durch die richtige Priorisierung des Product Backlogs in Kombination mit dem Pareto-Prinzip die Wirtschaftlichkeit von Software-Projekten erheblich gesteigert werden kann. Ein automatisiertes Testen ist dabei genauso wichtig wie ein automatisierter Releaseprozess und ein automatisiertes Deployment. Auch wenn das Automatisieren des Releaseprozesses relativ große Aufwände mit sich bringt, ist es besonders wichtig um die Vorteile der Agilität nutzen zu können. Leider wird dabei oft nicht erkannt, dass die Automatisierung des Releaseprozesses von Java-Projekten mit Java selbst viel aufwändiger ist, anstatt mit leichtgewichtigen Dingen wie Python-Skripten und Shell-Skripten. (Für den folgenden Satz entschuldige ich mich im voraus:) Der automatisierte Releaseprozess muss nicht besonders schön und tricky entwickelt sein, sondern funktionieren. Dennoch ist es korrekt. Der Releaseprozess soll nur funktionieren. Der Funktionsumfang ist überschaubar, aber es ist lästig, fehleranfällig und zeit-verschwenderisch die Releases immer wieder von Hand zu bauen.

Ein spannender Vortrag war sicher auch der Vortrag „Wer braucht ausführliche Dokumentation?“ von Markus Schramm (compeople AG). Der durchaus provokante Titel war sehr gut gewählt. Neben der Frage nach dem „Wie?“ wurde auch nach dem „Was?“ und „In welcher Form?“ gefragt. Für mich habe ich mitgenommen, dass man auf abgefahrene proprietäre Formate verzichten sollte, wenn man seine Dokumentation schreibt. Vielmehr muss der Einsatz von Wikis an dessen Stelle treten. Dinge bzw. Schnittstellen die nach außen gegeben werden sollen, sollten auch zukünftig eine Dokumentation in Form einer Word-Dokuments oder eines PDFs besitzen. Im internen Bereich jedoch ist es in der agilen Welt wesentlich wertvoller den Mut zu zeigen, dass fachliches Wissen statt in einer wasserdichten Dokumentation in den Köpfen der Mitarbeiter existiert. Das klingt im ersten Moment abgefahren, aber im Ernst: Was macht ein Entwickler, wenn er an einem unbekannten System arbeiten soll zuerst? – Er erkundigt sich bei jemandem, der das System kennt, statt in Eigenbrödler-Manier eine möglicherweise veraltete und unvollständige Dokumentation zu lesen. Dieses KnowHow über eine Software-Komponente sollte dabei über Reviews innerhalb des Teams gestreut oder im Falle der Mitarbeiterfluktuation in Form einer Übergabe weitergegeben werden. Eine solche Übergabe soll dabei allerdings nicht nur an einen anderen Mitarbeiter, sondern an zwei bis drei andere Mitarbeiter erfolgen. 80 Prozent der Dokumentation können dabei mit Wikis und JavaDoc ausreichend dokumentiert werden und 20 Prozent der Dokumentation dienen der Beschreibung der nach außen gerichteten Schnittstellen. Auch wenn der der Titel der Veranstaltung sicherlich absichtlich provokant gewählt war, ist die Frage tatsächlich notwendig. Welche Dokumentation brauche ich wann? Bin ich vom Gesetzgeber an die Einhaltung einer Dokumentationsstruktur gebunden (Stichwort: Datenschutz)?

Jens Coldewey (it-agile) hat in einem Vortrag mit dem Titel „Langfristige Planung in agilen Vorhaben“ festgestellt, dass es eine „Langfristige Planung“ gar nicht gibt. Planung ja, aber langfristig!? – Das ist nicht möglich, da man langfristig mit zu vielen unvorhergesehenen Dingen konfrontiert wird. Die Velocity eines Scrum-Teams zum Beispiel sinkt daher durch unvorhersehbare Ereignisse von Sprint zu Sprint exponentiell. Um feststellen zu können zu welchem Zeitpunkt der „80/20-Punkt“ eines Projekts – der Zeitpunkt, an dem 80 % der geforderten Anforderungen umgesetzt wurden – erreicht ist, sollte man die Velocity des Scrum-Teams mitschreiben und analysieren.

In einem weiteren Vortrag der Telefonica o2 Germany GmbH & Co. OHG und der C1 SetCon GmbH wurden die Erfahrungen aus einem agilen Outsourcing-Projekt dargestellt. Auch hier habe ich auf meinem Block einige Notizen gemacht. In dem vorgestellten Beispiel wurde darauf hin gewiesen, dass es nicht zu vernachlässigen ist, dass der Teambuilding-Prozess eines Scrum-Teams Zeit braucht. Das ist eine durchaus ernst zu nehmende Erkenntnis. Nach meinem Eindruck kranken viele Projekte daran, dass die Entwickler nicht ausreichend Zeit bekommen, dass „Miteinander“ zu finden. Auch in dieser Veranstaltung wurde wieder auf das „Wie?“ der Dokumentation hingewiesen und die Erfahrung berichtet, dass Word- und Excel-Dokumente viel zu weit weg von der Software-Entwicklung sind. Stattdessen solle man sich lieber auf Wikis und JavaDoc konzentrieren. Auch das ist für mich absolut nachvollziehbar. Word-Dokumente, die auf irgendwelchen Netzlaufwerken aufgehoben werden, veralten schon zum Zeitpunkt der Speicherung. Auch wenn der Inhalt eines solchen Word-Dokuments absolut wichtig und brauchbar ist, ist er in einem Word-Dokument total falsch aufgehoben. Es können keine Revisionen gespeichert werden und es können auch nicht mehrere Autoren gleichzeitig an der Dokumentation schreiben. Ein Wiki hingegen bringt in der Regel all diese Funktionen von vorn herein mit und ist auch vollständig durchsuchbar. Bei einer Komponente, die im Rahmen diesen Projekts, von insgesamt 3 Scrum-Teams mit jeweils 8 Entwicklern bearbeitet wurde, wurden Team-übergreifende Konfliktpotenziale gefunden. Jedes Team sollte deshalb eine Code Ownership für den von ihm bearbeiteten Bereich übertragen bekommen, der mit den Bereichen der anderen Teams interagiert.

Im Großen und Ganzen kann ich als Fazit feststellen, dass wir in der Software-Entwicklung des Kraftfahrt-Bundesamts schon relativ fortgeschritten mit der Nutzung agiler Methoden sind. Auch wenn man sich nicht an den Negativbeispielen misst, stelle ich an dieser Stelle fest, dass es in der Wirtschaft teils große Unternehmen gibt, die diesbezüglich erheblich mehr Nachholbedarf haben. Das hat mich total erstaunt, da man so etwas von einer Bundesoberbehörde in der Regel absolut nicht erwartet. Trotzdem ist es wichtig am Ball zu bleiben und sich kontinuierlich weiter zu entwickeln.

Erstklassige Idee! Dass ich da nicht drauf gekommen bin so etwas zu bauen, beschämt mich zwar nach wie vor etwas, aber dennoch war das seit langer Zeit mit Abstand der schönste Virus. Großartige Idee! Großartige Umsetzung! Gegen so etwas ist der normale Anwender machtlos.

Warum muss ich so oft aufs Klo?
Dieser Zustand wird manchmal von einer sogenannten Diarrhoe auslöst. Schweinekram!

Warum muss ich zur Schule gehen?
Wer sich diese Frage stellt, der muss dort eventuell nicht mehr hin. Wahrscheinlich ist es dann auch zu spät. Die Frage Warum muss ich mich immer melden? fällt dann auch automatisch weg.

Wieso ist der Kopf dicker als der Hals?
Schwierige Frage. Standardmäßig ist der Kopf dicker als der Hals, weil es sonst sicherlich scheiße aussehen würde. Bei mir persönlich ist es allerdings wechselhaft. Jedes Mal wenn unsere derzeitige Arbeitsministerin ein Interview gibt, dann ist bei mir der Hals dicker als der Kopf.

Was passiert wenn ein Staat bankrott geht?
Dieses Phänomen konnte ich nicht klären. Alle Fachartikel waren in griechischer Sprache verfasst.

Ich könnte jetzt noch unzählige Fragen beantworten. Das würde aber sicher einen eigenen Blog erfordern. Es ist unglaublich was ich jetzt für Fragen nie wieder aus meinem Kopf bekommen werde. Ich empfehle die Recherche mal selbst nachzuvollziehen.

P.S.: Warum die Musik plötzlich lauter wird müsst ihr mich nicht fragen. Die iMovie-iPhone-App meinte scheinbar dass es so sein muss.