Roland Dürre
Freitag, der 11. März 2016

„Inspect-and-A­dapt“ deine Schätzungen!

td-logoIch gehe immer gerne zum TechTalk der Techdivision in München. Das ist eine für mich attraktive Veranstaltung, die mein Freund und PM-Camp-Komplize Sacha Storz organisiert. Der nächste Termin ist am Mittwoch, den 16. März 2016 von 19:00 bis 20:30. Das Ende ist früher als sonst, damit die Besucher die Möglichkeit haben, rechtzeitig zum Bayern-Spiel vor dem Fernseher zu sein. Die Veranstaltung findet in den Räumen der TechDivision in der Balanstr. 73 (Haus 8, 3 OG) in 81541 München statt.

Hier die offizielle Ankündigung:

In der agilen Softwareentwicklungen nehmen Schätzungen von User Stories in der Planung eines Projektes eine zentrale Rolle ein. So führen ungenaue Schätzungen beispielsweise zu Überschreitungen des geplanten Budgets und des angedachten Zeitraums.

In einer Studie bei der TechDivision untersuchten wir die User Story Schätzungen in vier verschiedenen Projekten. Das Ziel dabei: Probleme identifizieren & Verbesserungen einbringen. Ein bekanntes Prinzip – denn schließlich gilt Scrum selber auch als ein „Inspect-and-Adapt“ Framework.

Aber: Wie könnte so etwas in Bezug auf Schätzungen aussehen? Und wie stehen die Ergebnisse der Studie in Bezug zur Diskussion um #NoEstimates?

Ich finde das Thema sehr interessant, bin ich doch ein Anhänger der sicher ein wenig provokanten These „Don’t estimate“ und kann dies auch trefflich begründen. Zusätzlich motiviert mich, dass mein Sohn Rupert der Vortragende ist.

Zum Redner:
imagesRupert Dürre ist als Consultant bei der schwedischen IT-Beratung Netlight tätig. Dabei interessiert er sich für unterschiedliche Bereiche in der agilen Softwareentwicklung vom Requirement Engineering, verschiedenen Entwicklungspraktiken bis hin zu der Fragee, wie man Teams organisieren könnte, um eine effektive Zusammenarbeit zu ermöglichen.

Anmeldung:
Die Veranstaltung ist kostenfrei, um Anmeldung wird gebeten. Hier geht es zur Website der Veranstaltung.

Dann bin ich mal um am nächsten Mittwoch um 19:00 in der Balanstraße und freue mich, wenn ich dort viele Freunde treffe!

RMD

Hans Bonfigt
Montag, der 28. Dezember 2015

Ganz agil vorbei am Ziel

Wenn man vor lauter Meta-Ebenen den Boden der Tatsachen nicht mehr sieht …

Die Spatzen pfeifen es von den Dächern: Nur etwa 20 Prozent aller Softwareprojekte funktionieren so, daß sie die Anforderungen erfüllen. Mit anderen Worten: Die Ausschußquote beträgt 80 Prozent:

  • 20% der Projekte scheitern, weil schlichtweg so falsch geplant wurde, daß sie gar nicht zu realisieren sind
  • 20% scheitern an Kommunikationsproblemen zwischen Auftraggeber und Entwickler
  • 20% werden aufgrund von Selbstüberschätzung der Entwickler nicht fertig und
  • 20% verenden, weil eingebundene Module von Drittanbietern nicht das leisten, was erwartet wurde

Von den verbleibenden 20 Prozent kann man mehr als die Hälfte getrost in die Tonne hauen, weil es entweder an Stabilität oder an Performance mangelt.

Nur in zehn von hundert Fällen liefern Softwarefirmen also das ab, was erwartet wurde – eine erschreckende Bilanz, die noch furchtbarer aussieht, wenn man das Kriterium „Termintreue“ hinzuzieht.

„Da muß doch ‚was zu machen sein“, dachten sich viele Leute, und der Schuldige war ganz schnell ausgemacht:

Der Wasserfall.

„Bitte reinigen Sie mein Auto“, mit diesen Worten übergab ein Firmenchef etwa zweimal im Monat den Mercedes-Schlüssel an seinen Prokuristen. Bevor hier Zweifel entstehen: Diese Abläufe habe ich Ende der 80er Jahre mehrfach persönlich erleben dürfen. Der Prokurist sah das Fahrzeug nach evtl. darin verbliebenen vertraulichen Dokumenten oder kompromittierenden Gegenständen durch und übergab den Auftrag an den Buchhaltungsleiter, der wiederum delegierte an seinen Chefbuchhalter, welcher seinerseits einen Lehrling verdonnerte. Am Samstagmittag reiste zuerst der Buchhalter an, um die Arbeit des Lehrlings zu begutachten, das Fahrzeug auf eventuelle Beschädigungen zu prüfen und danach erforderlichenfalls noch einmal selber Hand anzulegen. Kurze Zeit später holte dann der Buchhaltungsleiter das Gefährt ab, verbrachte es in die Remise des Chefs, wo bereits der Prokurist wartete, um die evtl. entnommenen Gegenstände wieder einzulegen sowie den Schlüssel persönlich an seinen Gebieter zurückzuüberstellen.

Besonders effizient war das sicherlich nicht. Dummerweise jedoch wurden und werden viele Softwareprojekte nach diesem Schema abgewickelt. Denn die Theorie ist äußerst verlockend:

  • „Oben“ gibt es wenige, die den nötigen Überblick  und damit den Kopf frei haben für die wirklich strategischen Entscheidungen
  • „In der Mitte“ können die taktischen Entscheidungen auf mehrere kompetente Spezialisten aufgeteilt werden und
  • „unten“ kann die zeitaufwendige Codierarbeit von vielen, ggfs. austauschbaren Programmierern schnell erledigt werden.

Das hört sich zunächst einmal schlüssig an. Und um es klar zu sagen: So hat das früher auch einmal funktioniert, und zwar erstaunlich gut. Es bleibt aber nichts, wie es war.

Eins vorweg: Eine monokausale Erklärung, warum der „Wasserfall“ nicht mehr so funktioniert wie früher, kann für solch ein komplexes Phänomen niemals ausreichen. Die nachfolgende Polemik, soweit möchte ich mich aber doch vorwagen, „erschlägt“ einen nicht ganz so kleinen Anteil der Fälle.

Der Ärger fing an mit der Verbreitung des PC. Bevor diese scheußlichen Kisten den Massenmarkt überschwemmten, besaßen Unternehmen typischerweise eine einzige Rechenanlage, und die war extrem wichtig. Deswegen wurde diese gehegt und gepflegt, und zwar von einem gut aufeinander abgestimmten, qualifizierten Team. Es dauerte mitunter Jahre, bis ein neuer Mitarbeiter administrative Rechte bekam. Der Beruf des „Admins“ oder des „Programmierers“ war geprägt von Kontemplativität. Die Maschine zeigte einem oft und unnachgiebig die eigenen Fehler und Grenzen auf, andererseits aber forderte sie häufig, daß man ihre eigenen, zumeist durch die Hardware „eisern“ festgelegten Restriktionen mit neuen Verfahren neutralisierte. Dazu mußte man dieses Ding gut kennen. Ein Assemblerlauf dauerte gerne auch einmal 2 1/2 Stunden, Fehler im Quellcode gab es immer und wer da nicht zwischen den Tests im Maschinencode „patchen“ konnte, der assemblierte sich zu Tode. Das galt sinngemäß für „Hochsprachen“, und so war es selbstverständlich, daß man sehr genau wußte, was genau ein Compiler aus einer PERFORM- oder COMPUTE – Anweisung machte. Man war auch gezwungen, sich bei der Lösung eines Teilproblems genau zu überlegen,

  • soll es besonders schnell ausgeführt werden,
  • soll es möglichst wenig Hauptspeicher belegen (ein unwahrscheinlich wichtiges Kriterium seinerzeit) oder
  • soll es möglichst portabel und, fast immer damit einhergehend, selbstdokumentierend sein?

Unterließ man diese Vorüberlegungen, fiel einem schon das Teilproblem fast unweigerlich schmerzhaft auf die Füße.  Manchmal mußte man auch noch sehr „hardwareschonend“ programmieren, beispielsweise ein eigenes Caching implementieren, um Platten-, Disketten- und vor allen Dingen Bandeinheiten vor frühem Verschleiß zu schützen.

Seit langem arbeite ich in einem Unternehmen, welches nicht nur „Computerprogramme“, sondern manchmal auch komplette Anlagensteuerungen beispielsweise zur Polyesterextrusion entwickelt – vom Steuerprogramm selbst bis zu angepaßter Sensorik und Aktuatorik; wenn es irgendwie geht, verdrahte ich auch die Schaltschränke selbst. Typischerweise übernimmt bei größeren Anlagen der Steuerungsbauer auch die Rolle des Anfahrleiters. Bei der Erstinbetriebnahme, wo aufgrund kleinster Fehler ausgesprochen rohe Kräfte sehr sinnlos, dafür aber umso verheerender walten können, muß man sich auf seine Teamgefährten, aber auch auf die eigene Arbeit hundertprozentig verlassen können. Ein einziges verdächtiges Geräusch, rechtzeitig erkannt und richtig interpretiert, kann enormen Schaden verhindern. Dazu braucht man Menschen mit Erfahrung, Sorgfalt, Vorsicht und Demut.

Nun kamen in den 90ern die scheußlichen „PC“s auf den Markt, und urplötzlich war jeder sein eigener Admin und jeder präsentierte stolz irgendeine heimgebackene Detaillösung, die unter bestimmten Umständen sogar dann und wann funktionierte. Es begann eine grauenvolle Zeit der „dezentralen EDV“, in der jeder Mitarbeiter so eine Daddelkiste unter dem Schreibtisch hatte und auch gerne daran herumschraubte. Das „Fachpersonal“ nutzte die neuen, eigentlich bis heute vielfach völlig unnötigen graphischen Fähigkeiten der Geräte für immer albernere Spiele. Das Hauptproblem bei dieser Entwicklung hat mir einmal eine Psychologin erklärt:Wissen Sie, gern läßt sich eine verlassene Frau von einem Verehrer trösten — doch sie wird nie etwas mit diesem anfangen, nach dem Motto, „Wo ich kotze, eß ich nicht“. Es gibt aber nicht nur den Dipol „kotzen – essen“, sondern auch den Dipol „Spiel und Spaß — Arbeit und Verantwortung“

Vielleicht lag es daran: Wirklich ernsthaftes Arbeiten an PCs habe ich nie erlebt. Es hing ja auch keine Verantwortung daran: Wenn so ein Ding abschmierte, dann war der Schaden lokal begrenzt und alsbald festigte sich ein allgemeines Vorurteil, daß Computer nun einmal von Zeit zu Zeit gerne abstürzen – so einfach ist das. Irgendwelche Maschinen wurden auch nicht mit den Büchsen betrieben, also konnte auch niemand zu Schaden kommen.

Wo keine Verantwortung, da auch keine (Selbst-)Disziplin. Dieses Wort wird m.E. viel zu stark verteufelt, indem es in die autoritäre Ecke gedrängt wird. Dabei leitet es sich aus dem lateinischen ‚discipulus‘ ab, übersetzt am besten mit „Schüler“. Disziplin im positiven Sinne heißt Lernwillen, heißt auch, zunächst einmal deskriptiv anstatt normativ zu arbeiten.

In der PC-Szene will aber

  • jeder
  • immer
  • alles
  • sofort

mit „seinem“ Computer machen, und das knallt schon dann, wenn er alleine an seiner Daddelkiste sitzt, denn „machen wollen“ heißt ja noch lange nicht „machen können“. „Niedere“ Arbeiten haßt der Computerbeherrscher, welcher sich gern mit Künstlernamen wie „Merlin“ oder Bezeichnungen wie „Geek“ schmückt, von ganzen Herzen und besteht darauf, diese an die unwürdigen „User“ zu delegieren. Dabei ist gerade die handwerkliche Seite der Softwareentwicklung von größter Bedeutung. Genau so, wie es keine „minderwertigen Menschen“ gibt, gibt es auch keine „minderwertigen Arbeiten“. Richtig verheerend wird es dann, wenn viele Möchtegern-Herrscher, -Künstler und -Genies gemeinsam an einem Projekt arbeiten müssen, womöglich auch noch auf ein- und derselben Kiste.

Lieber Leser, soweit Sie es bis hierhin geschafft haben: Also, wenn Sie mich fragen, dann ist es in einer solchen Konstellation sehr erstaunlich, daß überhaupt fünf bis zehn Prozent brauchbare Produkte aus einer solchen Situation resultieren können.

Und deswegen haben ganz schlaue Menschen das „Projektmanagement“ erfunden, und eine Untergruppe dieser Menschen hat das „Agile Manifesto“ aus der Taufe gehoben:

Individuen und Interaktionen über Prozesse und Werkzeuge
Funktionierende Software über umfassende Dokumentation
Zusammenarbeit mit dem Kunden über Vertragsverhandlung
Reagieren auf Veränderung über Befolgen eines Plans

Hört sich gut an, nicht wahr? Oder sind Sie selber Softwareentwickler und sehen da vier dicke fette Ausreden von cleveren Böcken, die den Gärtner geben wollen?

 

Wie auch immer – irgendwann erwischt es jeden. Und hier mein ungeschminkter Erlebnisbericht „aus der neuen Welt“:

Es ist noch früh, als ich beim Kunden auflaufe, ich bin zum erstenmal dort. Man hat dort Probleme, ein selbstentwickeltes Programm auf die IBM POWER-Architektur zu portieren. Der Kontakt kommt über IBM zustande.

Man geleitet mich in einen größeren Konferenzraum. Dort sitzen schon vier Leute, jeder versteckt sich hinter seinem Rechner, drei „Apple“, ein „Vaio“. Rechts daneben haben alle „Smartphones“ neben sich liegen. Ich sage vernehmlich Guten Morgen, bekomme etwas zurückgenuschelt (der Stuttgarter Einheimischenslang ist schwierig) und setze mich auf einen der freien Plätze. Lege mir Block und Druckbleistift zurecht und prüfe nochmal, ob das Mobiltelephon ausgeschaltet ist.

Die Empfangsdame war ein junger Mann und entsprechend wurde mir kein Kaffee angeboten. Auch keiner der Anwesenden fühlt sich bemüßigt, einem Gast, der etwa 700 Km weit angereist ist, irgendetwas anzubieten. Irgendwann kommt eine junge Frau, welche im bald beginnenden Rollenspiel die „Project Owner“ gibt. Das ist die bedauernswerte Person, die den Ärger mit den Endkunden hat. Nett angezogen, spricht hochdeutsch und war wohl die, die angeregt hat, einen Externen hinzuzuziehen. Das genaue Gegenteil ist die „Scrum Mistress“, die den „Spielablauf“ steuert.

Letztere stellt mich vor, ich sei von außerhalb und könne vielleicht helfen. „Wo haben Sie Ihr Notebook?“ fragt sie mich, worauf ich antworte, „Ich bin zum Arbeiten hier“. Als das kollektive Getipsel abrupt aufhört, wird mir klar, daß von den mittlerweile 12 anwesenden Personen 11 so ein Knaddeldaddel vor sich haben.

„Aber ein Kaffee wäre nicht schlecht“, versuche ich den gelungenen ersten Eindruck noch zu toppen.

Am Klondike

„… dwelt a miner, fourtiy-niner, and his daughter Clementine“: Im Rahmen einer Agilen Retrospektive soll ich Projekt und Status erfassen. Ein mühsames Geschäft: Ich komme mir wirklich vor wie ein mäßig erfolgreicher Goldgräber, der Fakten-Nuggets aus dem Informationsstrom filtert. Zwei anstrengende Stunden brauche ich, um zu erfassen, worum es eigentlich geht:

Gescannte Dokumente (die SCRUM-Drum sagt immer „eingescannte“) sollen aufgrund von darauf befindlichen Barcodes automatisch bestimmten Anwendungen zugeordnet werden, typischerweise den Anwendungen, welche für die Barcodes verantwortlich waren. Auf den ersten Blick hört sich das blödsinnig an, aber in der Praxis ist dies sehr wichtig, weil im täglichen Betrieb sehr viele maschinell erstellten Belege später, teilweise durch Kunden und Partner, modifiziert oder signiert werden. Der Scanner also als „Datenklo“, wo man alle anfallenden Belege ‚reinsteckt nach dem Motto, „den Scheiß bin ich erst mal los“.

Es wird ungefähr 65.536 mal versichert, daß das Datenklo im eigenen Hause prima funktioniere, bloß nicht auf dem bösen Zielrechner des Distributors.

Der Überblick fehlt: Es gibt niemanden, der mir, quasi in Form eines Blockdiagramms, die beteiligten Module auf die Reihe bringen kann.

Wo viele verantwortlich sind, ist es am Ende keiner mehr: Eine Testmaschine im Hause existiert nicht! Mir bleibt der Mund offen stehen (aber nur kurz, danach frage ich zur Sicherheit nach, ob ich mich hier in einer Softwarebude befinde oder bei einem rheinischen Tuntenballett – für letzteres spreche nicht nur die hohe Anzahl an Apple-Geräten). Auch der „PO“ scheint der Umstand, daß man nicht einmal eine Testmaschine vor Ort hat, völlig neu zu sein: Ihr angenehmer Teint bekommt eine Spur Purpur dazu. Die SCRUM – Drummerin dagegen bekommt rote Flecken im Gesicht und meint, das sei genau richtig und beabsichtigt so und außerdem stehe die Inbetriebnahme einer Testmaschine auch in den Anlagen zum „Burn-Down-Chart„.

Studieren geht über Probieren: Auf dem Burnout-Chart kann man sehen, wieviele Aufgaben noch erledigt werden müssen. Dabei hat man das gleiche Problem wie ein Mikroprozessor mit seinem Instruktionsstrom: Wie vielen älteren Menschen bekannt, wird eine Instruktion ja nicht in einem Takt vom Rechner abgearbeitet, sondern durchläuft typischerweise zwischen 16 und 24 „Bearbeitungsstufen“. Wenn die „Pipeline“ erst einmal gefüllt ist, fällt mit jedem Takt eine abgearbeitete Instruktion an (also, jetzt nicht bei Intel und Konsorten, sondern bei ordentlichen Konzepten). Dumm nur: Manchmal gibt es Sprünge innerhalb eines Programmes und dann heißt es für die Pipeline, die bisher linear nachgeladen hatte: „Zurück auf Start, alle Planung war für’n Arsch“. Fast genauso schlimm wirkt sich die sehr häufig vorkommende Situation aus, die entsteht, wenn aufeinanderfolgende Arbeitsschritte voneinander abhängig sind:

Dann muß halt so lange gewartet werden, bis der Vorgänger fertig ist. (Ja, ‚branch prediktion‘ ist mir ebenso bekannt wie ’superpipelining‘, hier geht es ums Prinzip). Mit dem Burnout-Chart wird geplant wie mit einem schlecht konfigurierten SAP-System, indem davon ausgegangen wird, daß alle Arbeitsschritte gleichzeitig und voneinander unabhängig seien. Ein Anstreicher kann aber kein Haus anstreichen, dessen Mauern noch nicht gesetzt sind. Die ganzen Schätzungen fallen wie ein Kartenhaus zusammen, wenn es, wie jetzt, einmal ernsthaft klemmt und keine Auswege da sind. Bevor man detailreich etwas postuliert, heißt es: „Vorher ausprobiert!„.

PPPPPP: Proper Preflight Planning Prevents Poor Performance! Sonst kommt es zu einem Kollaps, den Judith Andreesen gut beschrieben hat, überdies, völlig branchenuntypisch, in einer klaren, angenehmen Sprache: Die Reißleine ziehen. Überhaupt hat sich die Autorin erkennbar viel Mühe mit ihrem Blog gemacht. Korrektur: Nicht erkennbar viel Mühe gemacht. Denn auch das zeichnet einen guten Text aus, daß er nicht nach Fronarbeit riecht, sondern leicht und angenehm daherkommt.

Not my department – oder „Schuld sind die and’ren, stellt mir keine Fragen“: Die PHP – Mannschaft meint, „was kümmert uns ein Architekturproblem, wo doch unsere Sprache genau dazu gemacht ist, um Architekturprobleme zu abstrahieren („und Zombies wie Euch zu generieren“, aber das kann ich gerade noch unterdrücken – in etwa weiß ich schon, wie weit ich zu weit gehen kann. Nicht einmal Rambo kommt ohne fremde Hilfe ans Ziel). Die Webtrottel also lehnen sich zurück und genießen die Show. Das wäre bei uns in der Firma nicht denkbar. Da packt jeder mit an, um Kollegen, denen die Krawatte klemmt, weiterzuhelfen. Nun sitzen wir übrigens schon seit gut drei Stunden zusammen – und keiner raucht! Das irritiert mich jetzt aber schon.

Selber habe ich vor 20 Jahren damit aufgehört, nicht aus prinzipiellen Erwägungen (intelligente Menschen haben sowieso aus Prinzip keine Prinzipien, weil sie sie prinzipiell nicht brauchen. Doch ich wollte einmal im Leben einen Kampf gegen meine eigene Fremdbestimmtheit gewinnen). Aber jetzt vermisse ich den würzigen Duft einer leckeren Zigarette. Man sitzt in einem Boot, gemeinsam raucht man eine Zigarette, die entweder die kreative Lösungsidee bringt oder, wer weiß, als legendäre „letzte Zigarette“ das gemeinsame Ende besiegelt. Da kommen Emotionen auf! Nicht: „Wir schaffen das!“, sondern: „Wir wollen das!“. Ich frage, ob es irgendwo hier einen nahegelegenen Park gibt, damit man sich die Beine vertreten kann und auf andere Gedanken kommt – die gucken mich an, als hätte ich Gruppensex vorgeschlagen.

Niedere Arbeiten – aber doch nicht für einen „Geek“! Einer meiner Mentoren und großen Vorbilder war jahrelang Leiter der Motorenentwicklung bei seinerzeit IHC, heute bekannter unter dem Namen Case. Eine seiner Thesen war, man könne sowieso nur für ganz kurze Zeit eine kreative und konstruktive Arbeit leisten. Weil man aber schlecht 90 Prozent der Arbeitszeit Pause machen kann, nimmt man sich etwas anderes vor. Und merkwürdigerweise, genau bei diesen scheinbar „untergeordneten“ Aufgaben fallen einem die besten Ideen ein – oder, nicht so schön, aber nicht weniger wichtig, man entdeckt in einem winzigen Detail einen kapitalen Showstopper. Ich erinnere mich noch, als wäre es gestern gewesen – wir hatten ein Problem mit der sogenannten Werkzeugsicherung eines Stanzautomaten: Die Steuerung erkannte zu spät, daß ein Werkstück in einem schnellaufenden Folgeverbundwerkzeug klemmte, der Weitertransport sorgte für Überlagerung und das gewaltige polare Massenträgheitsmoment des Schwungrades der Exzenterpresse für einen kapitalen Maschinen- und Werkzeugschaden.

Mein Mentor „verdonnerte“ mich, die Maschine zu reparieren. Allein. Eine Drecksarbeit, nicht ungefährlich noch dazu. Beim Zerlegen der Drehkeilkupplung, welche die kraftschlüssige Verbindung zwischen Exzenter und Schwungrad herstellt, wurde mir klar, daß diese Verbindung bei einfacher Modifikation der Pneumatik auch noch zu einem wesentlich späteren Zeitpunkt getrennt werden konnte. Glücklicherweise hat das Unternehmen, für das ich arbeitete, bis heute noch einen Werkzeugbau und wir fertigten modifizierte Steuerkulissen und andere Komponenten selbst an. Der Leiter des Werkzeugbaus, obwohl kurz vor der Pensionierung, war mit Feuereifer bei der Sache. Nach drei Tagen lief die Maschine wieder und jahrelang gab es keinen Bruch mehr. Mein Mentor sah mich schräg an und meinte, „Das hätten Sie nie hinbekommen, wenn ich Sie nicht genötigt hätte, die Maschine selbst auseinander zunehmen“. Diese Erfahrung ist der Grund dafür, weshalb ich auch heute noch ganz gern das eine oder andere Modul selbst programmiere. Und sehr gerne irgendwelche Dinge zusammenlöte oder -schraube.

Peer Review: Nach einigem Suchen finden wir einige verdächtige „Hilfsprogramme“, welche aus einer Linux-Distribution stammen. Eines ist mir besonders suspekt. In C geschrieben, gespickt mit Abscheulichkeiten. Mein alter Deutschlehrer brachte mir eine interessante Definition nahe, „Kunst ist die konsequente Umsetzung eines Prinzips“. Hier war die Umsetzung so kaputt, daß das Prinzip angegriffen sein mußte. So wurde zum Beispiel abgefragt,

if (3==i) …

Irgendwelche Germanisten und Nichtprogrammierer haben sich das ausgedacht: Weil ausgemachte Anfänger in den ersten Tagen gern eine Wertzuweisung (=) mit einem Vergleichsoperator (==) vertauschen, wird doch allen Ernstes empfohlen, anstatt des lesbaren und unmittelbar verstehbaren ‚if (i==3)‘ so einen Blödsinn zu schreiben wie oben, denn eine Wertzuweisung an eine Konstante legt den Compiler auf die Nase. Der Anfänger ist „geschützt“ und alle Profis müssen sich jahrelang mit unleserlichem Programmkot herumärgern. Das orientiert sich an einer Lehrpädagogik, die an ein Rennrad Hilfsräder anschraubt: „Hier:  Mit unseren Stützrädern kann keiner mehr umfallen!“. Dumm nur: Mit dem Zusatzklapparatismus macht man aus einem einspurigen Fahrzeug ein mehrspuriges. Und wenn sich ein Profi mit dem „Schutz“ einmal sportlich und schnell in eine enge Kurve legt, fliegt er buchstäblich aus der Bahn, weil er seinen Schwerpunkt nicht mehr ins Kurveninnere verlagern kann und landet im Dreck. Ganz abgesehen davon: Wer „sicher“ und „geschützt“ programmieren möchte, der macht das sinnvollerweise nicht in C, sondern beispielsweise in ADA. Die Krönung: Im vorliegenden Fall steckte auch noch ein gehöriger logischer Fehler drin, denn eigentlich gemeint war: ‚if (i >= 3)‘ …

Es geht richtig fies weiter: Nicht nur „RTL – Castings“ sind stockpeinlich, auch bei der C – Programmierung erkennt man leicht den Stümper. Aus schierem Unverständnis heraus, was Indexregister („Pointer“) sind und wie ein C-Compiler sie interpretiert, werden Werte absolut zugewiesen. So was meckert der Compiler zu Recht an. Mit einem „Cast“, dem Elixier der „Aber bei mir funktioniert es doch!“ – Generation, kann man ihn ruhig stellen. So habe ich es gerne: Zwei Zeilen vorher den Sicherheitsfanatiker herauskehren und dann sozusagen den Brandmelder ausschalten.

Die nächsten Zeilen sind ein offener Angriff auf die abendländische Kultur:

for (…) sprintf (buf,string);

Die Standardfehler, zwei fiese, mißbrauchbare Sicherheitslücken, will ich gar nicht diskutieren. Wer „PHP“ einsetzt, der braucht sich um „Security“ keine Gedanken mehr zu machen. Viel schlimmer finde ich, daß

  • es dieser „teuren“ Funktion gar nicht bedurft hätte: Es werden vier konstante Buchstaben übergeben. Die Aufbereitung dieser vier Buchstaben wird an eine extrem mächtige Funktion übergeben, die die übergebene Zeichenkette lexikalisch analysiert.
  • bei „unpassender“ Parametrierung, beispielsweise mit einem Prozentzeichen im Funktionsargument, das Programm im günstigsten Fall undefiniert auf die Nase fällt.
  • bei jedem der extrem häufigen Schleifendurchläufe die „teure“ Aufbereitung erfolgt, obwohl man dies ohne Not außerhalb dieser Schleife hätte tun können.
  • der Rückgabewert der Funktion ignoriert wird. In diesem Falle wäre das o.K. gewesen, aber dann ist man so nett und benutzt tatsächlich einmal einen „Cast“, indem man ein  ‚(void)‘  vor die Funktion schreibt, um den Compliler am Meckern zu hindern („function returns value which is always ignored“) und den Kollegen anzuzeigen, „Hier habe ich bewußt auf eine Prüfung verzichtet“.

Das Allerschlimmste aber: Die Art und Weise, wie innerhalb der (in der Realität deutlich größeren) Schleife Daten übergeben und in eine Datei geschrieben werden, macht die Portabilität des Codes in Bezug auf die sogenannte Endianness kaputt. Die aufgebohrten „386er“ PC-Prozessoren sind typischerweise „Little Endian“, Mama Blue baut typischerweise „Big Endian“. In der Ausgabe landet jetzt nicht, wie beabsichtigt, „Y800“, sondern „008Y“.

Ich erläutere meinen Verdacht und ernte: Achselzucken. Denn die einzige im Raum, die die Erläuterung kapiert, ist die „nichttechnische“ Project Owneress. Später erfahre ich, daß sie gelernte Floristin ist. Was ich immer sage, „Informatiker meiden!“.

Crisis ?  What Crisis ?

Die Masteress geht jetzt mit SCRUM — vielfach ums Problem herum:

Es wird diskutiert, ob man einen laufenden „Sprint“ abbrechen sollte, um einen neuen zu beginnen, natürlich nicht ohne „Review„. Hat die noch alle Latten am Zaun? Das erste, was man jetzt vielleicht tun sollte, frei nach dem agilen Motto, „Individuen und Interaktionen über Prozesse und Werkzeuge“: Programmkorrektur, Kurztest auf im Hause vorhandener Intel-Spielarchitektur, Testrelease auf einen richtigen Computer packen (und zwar nicht auf die Endkundenmaschine, um diesen nicht weiter zu inkommodieren), dort nochmaliger Test.

Aber weit gefehlt: „Das paßt nicht in unser Tooling„.

Bei uns in der Firma sind wir ja der Meinung, daß man nur das verantwortlich einem Kunden empfehlen kann, was man selber im Einsatz hat, insofern haben wir natürlich auch zwei IBM POWER – Maschinen am Start und im Gegensatz zur INTEL-Welt gibt es dafür auch eine brauchbare Virtualisierungsplattform – ich könnte also innerhalb von kürzester Zeit eine Testumgebung bauen.

Nur leider: „Das ist in unseren Prozessen nicht vorgesehen“.

 

Wenn’s am schönsten ist, Freunde …

… dann muß man halt gehen. Das ist nicht mehr meine Welt. Ich erkenne schlagartig, daß wir „Informationstechniker“ längst zu dem geworden sind, was wir verachtet und bekämpft haben:  Wir sind die neuen Bürokraten. Bleistiftspitzer. Bürohengste. Tintenpisser. Anstatt unseren Job zu machen, „Verwaltung von Information“, beschäftigen wir uns längst fast ausschließlich mit der Verwaltung der Verwaltung. Die eigentlichen Probleme sind ganz weit weg.

Mir fällt noch eine prima Verbalinjurie für die Mannschaft ein, aber irgendwie bin ich gerade zu traurig, um sie auszukippen. Ich bedaure also, unter den gegebenen Umständen nicht die Hilfe gewesen zu sein, die man sich erhofft habe, aber die neue Welt würde mich überfordern – ich käme mir vor wie der „Ich“ – Erzähler in Umberto Ecos spannendem Krimi „Der Name der Rose“:  „sic stat printine nomine rosa, nomina nuda tenemus“.

 

Epilog

Schon drei Tage später bekommen wir Bescheid von der „PO“: Ja, man hat den Fehler bestätigen können. Er wird aber nicht behoben, sondern man hat im „sprint review“ nach langer Diskussion vereinbart, daß der Kunde seine „offensichtlich unzulängliche“ POWER – Maschine von „Big Endian“ auf „Little Endian“ umstellen muß. Denn, so hat man bei IBM erklärt, mit der neuen Generation der POWER-Maschinen könne man das einstellen und außerdem gäbe es da ein passendes „UBUNTU“ …

 

Fazit

  1. Wasserfälle sind wunderschön.
  2. Zwei Dinge sind aktueller als jemals zuvor:  Brechts „Anachronistischer Zug“ und, hier einschlägiger als man es sich wünscht: »Jeder Zuwachs an Technik bedingt, wenn damit ein Zuwachs des menschlichen Glücks verbunden sein soll, einen entsprechenden Zuwachs an Weisheit.«
  3. Endlich tut sich mir schemenhaft ein Erklärungsansatz für die epochemachenden Glanzleistungen der T-Systems auf.

Und ansonsten halte ich mich bei der Softwareentwicklung zukünftig wieder an eine Empfehlung von Eberhard v. Kuenheim:

„In großer Höhe fliegt der Adler besser allein“.

hb

Roland Dürre
Samstag, der 7. November 2015

Retrospektive der eigenen Gründung von 1983

logo-HITAuf der Suche nach dem HIT-Logo bin ich auf diesen Artikel gestoßen. Er beruht auf einem Interview, dass ich im August 2014 gegeben habe. War wohl im Rahmen irgend eines der (unübersichtlich) vielen öffentlich geförderten Mittelstands- und Gründungswettbewerbe. Eben so eine der vielen Förderungskisten. Den Namen des Redakteurs / Ansprechpartners weiß ich auch nicht mehr.

Der Artikel ist erschienen im:

header-1

Die Kernaussage des Artikel ist:

Meine eigene Gründung ging gut, weil viele notwendige Voraussetzungen erfüllt waren. Die wir aber nicht à priori rational geplant sondern erst à posterio erkannt haben.

Es ist ein persönlicher Bericht zur Gründung der InterFace AG. Ich veröffentliche ihn leicht modifiziert in IF-Blog.de, weil er ein Teil meiner persönlichen Geschichte ist. Ich möchte jungen Gründern Mut machen und schon mal auf meinen fast fertigen „vierten Beitrag in meiner Serie „Vintage Projekt Management“ einstimmen, der bald erscheinen wird. Hier der Text:

Seit Beginn der 80iger hat mich die Selbstständigkeit gelockt. Zum einen, weil ich (wie auch bei vielen mir bekannten Gründer von heute) ein Unternehmen eigenverantwortlich mitbestimmen und so auch mehr Freude an der Arbeit haben wollte, zum anderen, weil ich mehr Geld verdienen wollte. Ein Argument, dass erstaunlicherweise für viele der mir bekannten heutigen Gründer gar nicht mehr so wichtig ist – vielleicht weil die Einengung an vielen Arbeitsplätzen erdrückender wie früher geworden ist und viele Menschen nicht mehr bereit sind, für die Karriere ihr Privatleben zu opfern.

Für den Start habe ich schon Ende 1982 den „idealen Partner“ gesucht (nicht die „ideale Geschäftsidee“, weil ich damals schon der Meinung war, dass es diese nicht gibt). Auch den „idealen Partner“ zu finden war nicht leicht, aber glücklicherweise habe ich nach einem guten Jahr Wolf Geldmacher getroffen.

Er brachte große unternehmerische Kraft mit und war genauso wie ich bodenständig verortet. Mit Wolf ging die Gründung der „InterFace Connection Gesellschaft für Datenfernverarbeitung und Entwicklung von Software mbH“, dem Vorgänger der InterFace AG, schnell. Unser Thema war IT und Unix. Auf dem damals „neuen“ Unix wollten wir ein erfolgreiches Produkt bauen. Ein Produkt war uns wichtig, gingen wir doch davon aus, dass Dienstleistung nicht zu skalieren ist. Auch waren wir schon 1983 (vor der Gründung in 1984) in Sorge, ob Body-Leasing ein Geschäft von Dauer sein würde. Bei strenger Auslegung schien uns schon damals, dass das Geschäft mit Body Leasing („Arbeitskräfte-Überlassung“ AÜG) sich zumindest in einer gesetzlichen Grauzone befand.

So war klar, dass wir ein Produkt bauen wollten. Nach verschiedenen Ideen (Datenbank, Vernetzung …) hatten wir uns ein bürotaugliches Schreibsystem auf Unix entschieden. Als Namen haben wir ihm das gegeben, was es werden sollte, nämlich ein HIT. Aus heutiger Sicht ist uns da ein kühnes Unterfangen gelungen. Schon nach wenigen Jahren waren wir das mit Abstand erfolgreichste Textsystem auf Unix in Europa. Es war wie ein Traum!

In der Retrospektive habe ich Menschen und wesentliche Voraussetzungen oder Ereignisse gefunden, ohne die es nie geklappt hätte. Wir waren einfach zum richtigen Zeitpunkt unterwegs und hatten unheimlich viel Glück, dass vieles gepasst hat.

Das Gespann „Wolf & Roland“
Wir haben schon Anfang der 80iger Jahre beide an „agil, lean und open“ geglaubt. Wir waren für Selbstorganisation und Selbstbestimmung, haben unsere Ideen und unseren Anspruch formuliert und unsere Teams machen lassen. Das alles in großer Gemeinsamkeit.

Notwendige „Skills“
Meine Eltern hatten es 1960 geschafft, mich in Augsburg von der Wittelsbacher Volksschule auf die wirtschaftswissenschaftliche Oberrealschule Jakob Fugger zu bringen. Das war kein leichtes Unterfangen. Später wurde diese Erziehungsanstalt dann zum „wirtschaftswissenschaftlichen Gymnasium“ umbenannt (bis 1960 war es noch eine Handelsschule). Die Fächer Buchführung und BWL, die ich am “wirtschaftswissenschaftlichen Gymnasium” gelernt habe, waren für die Gründung durchaus nützlich, aber nicht zwingend notwendig. Was ich an der TUM in Informatik gelernt habe, war praktisch auch nicht verwertbar. Programmieren habe ich als Werkstudent bei Siemens gelernt. Im Labor bei Siemens habe ich Teamarbeit gelernt, im Vertrieb bei Siemens Kommunikation und bei Softlab das Geschäft.

“Die Methode“
Für die SW-Entwicklung hatten wir eine private Methode erfunden und gelebt, die ähnlich dem ist, was man heute SCRUM nennt. Wolf war der „SCRUM-Master“ (und mehr). Er war für die Technologie und die Menschen zuständig. Er hat die Kollegen zur Qualität gebracht und ihnen klar gemacht, dass sie Qualität leben und geben müssen, dies zu aller erst für sich selbst. Und ich war so etwas wie der „Product Owner“ und kaufmännische Leiter.

An unserem Erfolg haben ein paar Menschen beigetragen, bei denen ich mich ganz ganz sehr bedanken möchte:

Anton Böck
Stenografie und Schreibmaschine waren am Jacob Fugger bis 1960 Pflichtfach, zu meiner Zeit dann Wahlfach. Mein Vater zwang mich beides zu lernen, weil er die beiden Techniken als wichtigen Vorteil im Kampf des beruflichen Lebens bewertet hat.

Anton Böck war mein Lehrer in diesen Wahlfächern. In Steno war ich recht gut. Wenn ich zu Hause zum Lernen verurteilt war, habe ich an meinem Schreibtisch stundenlang Steno gemalt. Für mich war das wie Kaligraphie, wunderschön. Und meine Eltern haben geglaubt, ich würde lernen. In Wahrheit habe ich mich aber in so eine Art „meditatives Malen“ undso in meine Träume geflüchtet.

Herr Böck war ein strenger Lehrer und hat mich gemocht, auch weil ich ein Spitzenstenograf wurde. Er hat mich aber auch auf die Schreibmaschine gezwungen. Die Schreibmaschine habe ich gehasst und ich habe deshalb schon mit 16 davon geträumt, wie eine „schöne“ und „liebe“ Schreibmaschine funktionieren müsste. Es klingt vielleicht ein wenig lächerlich, aber ich bin mir sicher, ohne diese meine frühe negative Erfahrung mit dem Generieren von Text hätte die InterFace Connection nie  ein Textsystem entwickelt und wäre so nie zu einem doch relativ erfolgreichen Produktunternehmen geworden.

Hans Strack-Zimmermann
Hans war mein Mentor und der Mann, der UNIX in Europa und bei Siemens (hier unter dem Markennamen Sinix) groß gemacht hat. Ich hat mich mit seiner Vision begeistert und er hat an unser Team geglaubt. Und er hat uns kräftig geholfen. So hat der Erfolg uns Recht gegeben.

Dr. Peter Schnupp

Peter war IT-Pionier der zweiten Generation (ich sehe die Generation Zuse als die erste und mich als Teil der dritten). Als Unternehmer (der Gründer von Softlab), IT-Experte, Kolumnen-Schreiber in der Computer-Woche und aufgrund weiterer Aktivitäten war er bekannt und hatte als Experte einen sehr guten Ruf.

Peter gelang es, für uns die strategische Entscheiderin einer Großbehörde zu überzeugen, dass die Zukunft der IT auf UNIX basieren würde und es da ein tolles lokales Produkt für Text gäbe.

Ohne diesen Glücksfall wäre das Projekt CLOU/HIT nie erfolgreich geworden.

Meine Projekte
Schon als junger SW-Entwickler bei der Siemens AG hatte ich in der Mitte der siebziger Jahre eine tolle Aufgabe. Im Rahmen der Entwicklung von Transdata habe ich das „Connection Handling“ entwickelt und an der Entwicklung von „APS“ (Anwender-Programmier-Sprache) mitgearbeitet. „Connection Handling“ ist von zentraler Bedeutung bei „Datenfernübertragung“, wie es damals hieß. Mit APS war es möglich, Verarbeitungsleistung schon in lokalen „Datenstationsrechner“ (Betriebssystem PDN) auszulagern und so erstmals das zentrische Prinzip der Main Frames zu durchbrechen.

Mit diesem „Herrschaftswissen“ konnte ich mich sehr schnell bei Großprojekten profilieren und wechselte dann ganz logisch zu einer Abteilung „Sonderprojekte Vertrieb“ bei der Siemens AG. Dort war mein wichtigstes Projekt DISPOL, ein zentrales Projekt der bayerischen Polizei, da sich Ende der siebziger und Anfang der achtziger Jahre die Aufgabe gestellt hatte den Aktenschrank (Daten), die Schreibmaschine (Dokumente) und den Fernschreiber (Kommunikation !) durch die Einführung von EDV abzulösen.

Dieses Projekt habe ich bis zur Gründung begleitet und verstanden, wie Markt und Kunden, besonders bei Behörden ticken.

Ohne diese Vorgeschichte wäre HIT/CLOU niemals ein erfolgreiches Produkt geworden.

Die Menschen bei InterFace
Wir haben für die Produktentwicklung ganz jungen Menschen eingestellt, die oft noch als Studenten zu uns kamen. Und es waren (fast) immer die richtigen. In rasanten Tempo haben diese Menschen sich zu zentralen Leistungsträgern entwickelt und eine hohe Verantwortung übernommen.

Richtige Prinzipien
Ergänzend zur Produktentwicklung hat sich wie zufällig eine qualifizierte Beratung und Zusammenarbeit mit Siemens im Bereich „Unix-Betriebsystem“ entwickelt. Wir saßen fachlich an der Quelle und haben bei unserem Betriebssystem-Partner vieles gelernt, das uns sehr geholfen hat. So haben wir früh Werkzeuge genutzt, die in Europa noch gar nicht verbreitet waren. Und viel Neues geschaffen, wie den “National Language Support (NSL), der dann sogar in XOPEN aufgenommen und Basis aller Unix-Systeme wurde.

Wir haben Methoden angewendet (oder besser intuitiv erfunden) wie das 4-Augenprinzip beim Programmieren, peer2peer-Reviews, „extreme programming“, Entwickler-Rotation und manches mehr. Das waren Methoden, die es damals noch gar nicht gab bzw. uns nicht bekannt waren. Aber es war einfach sinnfällig, es so zu machen. Das brachte uns aber mehr als wesentliche Vorteile betreffend Entwicklungsgeschwindigkeit, Anwenderorientierung und Qualität.

Unsere Entwickler hatten immer direkten Kundenkontakt. So haben unsere Entwickler die HIT-Schulungen für die Endkunden selbst gehalten und so die Kundenwünsche verstanden. All das hat wesentlich zur Güte des Produktes beigetragen.

Finanzierung
Die Schwierigkeit unseres Vorhabens war uns bewusst. So haben wir in der ersten Phase der Grundentwicklung uns den Aufwand mit IF-Computer geteilt. Für die zweite Phase der Vermarktung hatten wir eine Aufgabenteilung vorgesehen. Die InterFace Connection hat das Produkt weiterentwickelt und den Groß-Kunden Siemens betreut. InterFace Computer hat die Portierungen auf die vielen anderen Unix-Systeme und den Vertrieb für weitere Hardware-Hersteller und Partner übernommen bis dann die InterFace Connection das Gesamtthema übernommen hat.

Die Entwicklung eines Produktes brauchte eine kräftige „man power“. Und Menschen kosten Geld. In 1984 und dem folgenden Jahr lösten wir das auf eine einfache Art und Weise. Wolf Geldmacher und ich verdingten uns als Berater. Um Produkt und Team kümmerten wir uns an den Abenden und bei Bedarf Samstagen.

Als Berater hatten wir einen Stundensatz von 150,- DM. Das war herausragend und nur durchzusetzen, weil amerikanische Consultant mit vergleichbarem Know-how deutlich teurer waren.

Jetzt kann man mal einfach rechnen: Ein guter Monat bringt 200 Mannstunden (wir waren sehr fleißig). Mit 150,- DM multipliziert waren das schlappe 30.000 DM in guten Monaten. Bei unserem Gehalt damals von 5.000 DM, brutto als so um die 6.000 blieben 18.000 für Hardware, die Heidi (unsere Assistentin, die von Anfang an dabei war) und unsere Studenten, die Produktentwickler.

Schon wenige Monate nach der Gründung am 1. April 1984 konnten wir noch ein paar junge Informatiker für uns gewinnen und die sofort als Consultant einsetzen. Diese erbrachten Überschüsse in ähnlicher Höhe, die wir auch komplett für die Produktentwicklung eingesetzt haben. Und ab Ende 1985 hat dann das Produkt für schnell steigende Deckungsbeiträge gesorgt.

Die Ereignisse
Es gab weiter eine Reihe von glücklichen Umständen, die uns sehr geholfen haben.

So hatte Siemens ein sehr großes Projekt gestartet mit dem Ziel der Entwicklung eines eigenen Textsystems für BS 2000 und Unix. Obwohl diese Projekte mit einer Personalstärke besetzt waren, die eine mehrfacher Kopfstärke hatte als unser Entwicklungsteam und auch die Entwickler in den Siemens-Projekten alle gestandene SW-Entwickler waren, kamen diese Projekte nie auf einen grünen Zweig und sind dann mehr oder weniger komplett gescheitert.

Der Konzern Siemens brauchte aber solche Software für seine Ziele und musste bei zwei Lieferanten in Lizenz zu kaufen – einer davon waren wir. So wurden wir auf Unix der Lieferant und Lizenzgeber des damaligen Marktführers in Deutschland.
Das „technische“ Zeitfenster war auf unserer Seite: Unix löste damals die zahlreichen verschiedenen Rechnersysteme der „mittleren Datentechnik“ MDT ab. Wir kamen mit unserem Produkt HIT genau zum richtigen Zeitpunkt .

Es war auch die Zeit, in der sich der Einsatz von Datenbanken stark verbreiterte. Brandneu wurde SQL als „query language“ auf natürlicher Sprachbasis definiert. Es gab sogar eine deutsche Fassung von SQL! Was lag näher als die HIT ergänzende 4GL (Programmiersprache der 4. Generation) CLOU zur Programmierung von Textbausteinen um eine „embedded SQL“ zu erweitern, die es plötzlich möglich machte während des Ablaufs des Baustein-Programms dynamisch generierte Abfragen an eine Datenbank zu senden und die gefunden Daten dann automatisch bei der Dokument-Erstellung zu nutzen. Das war eine richtige Sensation, die auch genau zum richtigen Zeitpunkt kam.

Viel Glück und nur ein wenig Pech
Der Mut einer großen Bundesbehörde, auf eine völlig neue Technologie eines ganz kleinen Herstellers zu setzen, war sicher etwas besonderes. Eine wunderbare Marktentwicklung zu Gunsten von UNIX. Zahlreiche weitere mutige und für uns glückliche Kundenentscheidungen. Ein Super-Team …

Es gab auch Probleme
Die Beschaffung von Hardware für die Entwicklung war sündteuer. Schon 1985 mussten wir eine MX500 erwerben – die damals einen Listenpreis von über 300.000 DM hatte. Das war für uns unvorstellbar viel Geld. Es war aber klar, dass wir ohne dieses System die notwendige Entwicklungsgeschwindigkeit nicht schaffen würden. Schon zwei Jahre später gehörte diese Maschine zum alten Eisen, wir entwickelten auf SUNs, und über Nacht kamen neue schnelle PC’s mit diversen Unix-Varianten, die dann auch deutlich billiger waren.

InterFace Computer fiel aus, die strategische Kooperation funktionierte nicht mehr. So waren wir gezwungen, die Rechte am Produkt zu kaufen. Das war eine hohe Investitions und schwere Entscheidung, die sich aber im Nachhinein bezahlt gemacht hat.

Weitere notwendige Voraussetzungen

Es gibt da sicher noch mehr Ursachen, Zufälligkeiten, ohne die das Unternehmen HIT/CLOU gescheitert wäre. Zum Teil Dinge, die ich gar nicht mehr weiß oder mir so nicht bewusst sind. Aber ohne all das Beschriebene hätte es zumindest die InterFace Connection als Hersteller von HIT/CLOU nicht gegeben. Viele besondere Umstand und Zufälle haben zusammen bewirkt, dass es so gut geklappt hat.

Mit diesem Artikel möchte ich am eigenen Beispiel zeigen, dass viele Bedingungen erfüllt sein müssen, um Erfolg zu haben. Und das diese Dinge nicht geplant werden können. Das soll auch den (vernünftigen) Mut zu Lücke fördern, aber auch zeigen, dass gründen nicht so ganz einfach ist und ein pragmatischer Ansatz von herausragender Bedeutung ist.

RMD

craftsmanshipIn 2013 hatten wir bei der InterFace AG ein schönes „Fachliches IF-Forum“. Es ging um „Software Craftsmanship“. Wir hatten tolle Gäste und starke Referenten. Die Diskussion drehte sich um Fragen wie: Wie kommt man also zur Meisterschaft, wie gewinnt man die dafür notwendige Erfahrung? Wie entsteht die Motivation zu Perfektion? Wie schafft man Spitzenleistung und Qualität in Teams am besten?

Eine Aussage ist in diesem Workshop ist bei mir besonders hängen geblieben. Bernhard Findeiss berichtete damals (vielleicht auch ein wenig als Provokation gedacht), dass ein guter „Craftsman“, der es in seinem Handwerk zur Meisterschaft bringen will,  in der Woche bis zu 20 Stunden  für Weiterbildung aufwenden muss. Und dass dies in der Regel nicht in der Arbeitszeit geht, sondern zu einem oft nicht unwesentlichem Teil die Freizeit dafür herhalten muss.

Die Zahl hat mich zuerst überrascht. Ich musste daran denken, wie viele Menschen ihr Leben streng in Freizeit und Arbeit einteilen. Und habe mich an manche Diskussion mit Kollegen erinnert. Zum Beispiel wie viel Prozent der Weiterbildung denn als Arbeitszeit kontiert werden dürfen. So habe ich die letzten zwei Jahre viel über dieses Thema nachgedacht. Auf der einen Seite sind 20 Stunden pro Woche Üben und Lernen notwendig, will man es zur Meisterschaft bringen.

Dem stimme ich zu. Auf der anderen Seite braucht man noch viel Zeit, um für den Erfolg zu arbeiten. Und für Familie und Privates soll auch genug Zeit bleiben. Und ich meine es geht. Viele meiner Freunde – Fachleute, Manager und Unternehmer, männlich wie weiblich – leben und lieben ihren Job. Sie sind wirkliche „Meister“ und beschäftigen sich eigentlich immer mit den ihnen wichtigen Themen. Und sind trotzdem gute Ehepartner und Mütter wie Väter.

Ich bin jetzt in „Rente“. Und lerne und übe immer noch 20 Stunden. Nur ob ich ein Meister bin, da habe ich Zweifel. Aber ich werde weiter üben …

RMD

P.S.
Hier geht es zu den Videos vom IF-Forum Craftsmanship„.

P.S.1
Alle Artikel meines Unternehmertagebuchs findet man in der Drehscheibe!

Roland Dürre
Dienstag, der 3. Februar 2015

agile.ruhr Camp 2015

Vor kurzem habe ich mit Dominik Rose telefoniert. Da hat er mir berichtet, dass der Termin des von ihm gemeinsam mit Berthold Barth organisierten agile.ruhr Camp 2015 jetzt langsam näher rückt. Schon in weniger als drei Wochen ist es soweit!

„Agile“, das passt mir gut, denn meine Überzeugung ist ja, dass man alles wichtige immer „ALO“ angehen sollte. Wobei ALO als Abkürzung steht für Agile, Lean und Open.

agile-camp-ruhr-595x114

So freue ich mich, dass das Organisationsteam des agile.ruhr Camp in diesem Jahr erstmals zu einer „Unkonferenz“ für agiles Vorgehen im Projektumfeld und bei der Entwicklung von Software einlädt. Am 21. + 22. Februar 2015 ist es so weit, da findet das barcamp im Unperfekthaus in Essen statt.

Dass die InterFace AG mit von der Partie ist und das Orgateam als Sponsor unterstützt finde ich natürlich ganz besonders toll.

Das agile.ruhr Camp steht für Veränderung und Überzeugung. Ziel der Veranstaltung ist Menschen, Organisationen und Unternehmen eine moderne Plattform anzubieten, zum Teilen von Erfahrung und Wissen. Denn Wissen ist der einzige Rohstoff, der durch teilen mehr wird.

Wie kann man erfolgreich agile Methoden und Werkzeuge nutzen? Was wird durch agiles Bewusstsein und Handeln alles möglich? Wie schaffen wir die notwendige Veränderung? Und dies eben nicht nur bei der Entwicklung von Software!

Und natürlich bietet sich als der klassische Rahmen für eine freie Unkonferenz zu Agilität das Format „barcamp“ an, bei dem ganz bewusst im Gegensatz zur klassischen Konferenz auf eine einengende Agenda verzichtet wird und der redliche Diskurs im offenen Dialog überdurchschnittlichen Erkenntnisgewinn generiert.

Die Tagesordnung wird von den Besuchern festgelegt. Man duzt sich, Augenhöhe ist angesagt und Zuhören ist wichtiger als sprechen. Nur so werden können Teilhabe „ihre“ Sessions (zu einem Themenkomplex ihrer Wahl) anbieten und werden zu „Teilhabern“.

Leider kann ich persönlich am 13./14. Februar nicht dabei sein, da ich genau an den beiden Tagen bei einer ganz anderen „Unkonferenz“ sein möchte, bei der ich schon seit ein paar Jahren Stammgast bin – der „Biike“ in Westerland auf Sylt. Die „Biike“ ist nur ein Brauchtum, den Termin habe gute Freunde für ihre Nicht-Konferenz genutzt.
🙂 Das Leben ist eine Aneinanderreihung von verpassten Gelegenheiten.

Aber vielleicht kann ja der eine oder andere IF-Blog-Leser an meiner Stelle an diesem einzigartigen agile.ruhr Camp teilnehmen. Und dann in seinem Blog oder über Twitter darüber berichten.

RMD

P.S.
Wenn ich den Hashtag vom agile.ruhr Camp 2015 weiß, dann trage ich ihn hier nach.
Mein Vorschlag: #AgileRuhrCmp

P.S.1
In diesem Kontext etwas Lesenswertes zur InterFace AG.

Bauer-GoosEin wenig fühle ich mich als Informatik-Pionier der dritten Generation. Und denke gerne an meine ersten großen Projekte in den Siebziger Jahren des letzten Jahrhunderts zurück, die START, ITS, Dispol oder SNATCH hießen.

Für die zweite Generation der IT-Pioniere steht in meiner privaten Ordnung mein verehrter Professor F.-L. Bauer, bei dem ich 1969 im Herbstsemester an der TUM (damals noch TH für technische Hochschule) als Student der Mathematik meine erste Vorlesung in meinem Nebenfach Informatik hören durfte. Das abgebildete Buch ist übrigens mein erkennbar viel gelesenes persönliches Exemplar aus dieser Zeit.

Damals war das Thema Informatik etwas ganz Neues für mich. Und wahrscheinlich habe ich das Fach gewählt, weil ich nicht wusste, was es ist. Einfach, weil es irgendwie in die Zukunft gewiesen hat.

In der schönen Vorlesung von Professor Bauer habe ich so fast folgerichtig nicht alles von dem verstanden, was er uns mitgeben wollte. Sehr zu meinem Leidwesen.

BauerIn den letzten Jahren durfte ich Professor Bauer dann bei mehreren Führungen im Deutschen Museum in der Abteilung Informatik begleiten, die er für uns (InterFace AG) und unsere Kunden, Freunde und Partner gehalten hat. Da ist mir vieles klar geworden, was ich als junger Student noch nicht verstehen konnte.

Zur ersten Generation der Informatik zähle ich übrigens Menschen wie Konrad Zuse, den ich am Ende der InterFace-Konrad-Zuse-Radtour 1986 kennen gelernt habe. Er hat uns dort toll empfangen, eine wunderbare Rede gehalten und uns das abgebildete Bild beim großen Empfang in Hünfeld geschenkt, das heute bei der InterFace AG in Unterhaching hängt.

K_ZuseHeute ist die Informatik um „Lichtjahre“ weiter. Ich war und bin mit Herzblut Informatiker. Die Sinnkopplung zwischen meiner Arbeit, meinem Leben und der Gesellschaft war mir immer wichtig. Deshalb ist für mich die Entwicklung der Informatik wie ihre Zukunft wichtig. Beiträge von Dritten zu diesem Thema von herausragenden Vertretern der Informatik interessieren mich natürlich ganz besonders.

So habe ich in der 14. Ausgabe des TUM Magazins „Faszination Forschung“, einem hochwertigen Hochglanz-Magazin der TU München, in der Ausgabe vom Juni 2014 zum Thema „informatics“ den Artikel „Connecting the World“ gefunden.

Der Trailer zum Artikel liest sich so:

In future, everyday objects will be linked via the Internet, enabling them to interact autonomously. To realize this vision, computer scientists are developing virtual models they can use to test practical implementation and monitor the security, safety and reliability of connected systems

Der Artikel beschreibt die Zukunft der Informatik auf der technischen Ebene. Es geht hier vor allem um das Zusammenwirken von Systemen in einer zukünftigen „cyber-physikalischen Welt“. Da ich den Artikel lesenswert und als eine gute Diskussionsbasis empfinde, biete ich ihn hier zum „Download“ an: Cyber-Physical (692).

Mein Freund und Partner im Aufsichtsrat der InterFace AG, Professor Dr. Manfred Broy, wird dort zitiert und abgebildet. Es ist davon auszugehen, dass die Aussagen im Artikel zum Teil Ergebnisse der von ihm geleiteten Forschungsarbeit sind.

Ich bin mit dem Inhalt des Artikels nicht ganz einverstanden. Sicher wird es noch erstaunliche Entwicklungen in unserer Technologie geben, vielleicht noch verblüffender als die im Artikel beschriebenen. Nur an die Vorhersage der Anwendungsfelder glaube ich nicht, da ich annehme, dass die Gesellschaft der Zukunft ganz andere Herausforderungen haben wird, als wir sie uns heute vorstellen. Und wir dann sicher sehr aufregende Lösungen finden werden, die sich aber nicht in diese „schönen neuen Welt“ bewegen werden.

Spannend (und für mich bedenklich) wird es aber, wenn man die Entgegnung von Dr. Werner Meixner liest. Dr. Meixner ist wissenschaftlicher Mitarbeiter an der TUM und hat wohl in in einem Vortrag niedergelegt, wie dieser Artikel „auf jemanden (ihn) wirkt, der den Sinn seines Berufslebens wesentlich aus einer Faszination für Naturwissenschaften als einem humanistischen Wert versteht“.

Dieser Vortrag ist auch der Inhalt eines offenen Briefes an Professor Dr. Manfred Broy und hat zum Thema:
Wohin geht die Informatik?
Auch hier der Link zum Download des offenen Briefes von Dr. Meixner:
Wohin geht die Informatik? (704)

Um den IF-Blog-Leser auch hier zum Lesen anzuregen zitiere ich einen kurzen aber vielleicht zentralen Auszug aus diesem Artikel:

Jede menschliche Entscheidung, und das wissen Konzerne ganz genau, beinhaltet einen Wertschöpfungsakt und ist also wertvoll an sich. Das Wichtigste dabei ist, dass der Eigentümer dieses produzierten Wertes derjenige ist, der die Entscheidung getroffen hat und verantwortet. Dies genau ist die Bedeutung des Privaten, aus der auch die unbedingte Schutzwürdigkeit des Privaten folgt. Jegliche wirtschaftliche Tätigkeit ergibt sich daraus.

Ich verstehe die zitierte Aussage nicht so ganz. Wenn ich versuche, sie dialektisch zu analysieren, so meine ich einen willkürlichen Wahrheitsanspruch zu entdecken, der mir leicht widerlegbar scheint.

🙂 Ich schreibe aber an niemanden offene Briefe, da ich ein Blogger bin. Und BLogger schreiben keine öffentlichen Briefe sondern bloggen. So veröffentliche ich meine Meinung in meinen Blog.

Also:
Den Artikel im TUM-Magazin finde ich zu eindimensional technologisch, der „offene Brief“ hat mich bestürzt.

In beiden Artikeln nehme ich ein Welt- und Menschenbild wahr, das der von mir als real wahr genommenen Wirklichkeit nicht gerecht wird. Der erste erinnert mich ein wenig an die (damals ja von wirtschaftlichen Interessen gesteuerte) Euphorie zur Kernkraft vor mehr als 50 Jahren, der andere überhöht die Bedeutung des Privaten und lamentiert über dessen Schutzwürdigkeit, die nach meiner Lebenserfahrung und meinem Wissen aus Anthropologie, Gehirnforschung, Psychologie, Philosophie aber auch Soziologie überhaupt nicht zu rechtfertigen ist. Sogar mit theologischen Begründungen dürfte dies misslingen.

Die Herausforderungen für uns alle werden zeitnah andere sein als die beschriebenen. Nicht das Traumbild einer total vernetzten Welt wird uns helfen, diesen Herausforderungen zu begegnen noch der krampfhafte Schutz unserer privaten Daten, die letztendlich eh nicht geschützt werden können.

Die aktuellen Nachrichten, sei es von den Fronten der IS, von den sonstigen Kriegen mit ihren Folgen, von den Flüchtlingen die in die EU drängen, von dem Attentat aus Frankreich oder zu #Pegida und #Anti-Pegida in Deutschland sind deutliche Anzeichen einer sich beschleunigt verändernden Realität, die wir akzeptieren müssen. Und mit der wir vernünftig umgehen müssen.

Die Vorherrschaft der globalen Wirtschaft, die total freie Märkte für Waren schafft aber die Arbeit unfrei lässt (eine Näherin aus Bangladesch kann ihren Arbeitsplatz nicht nach Europa verlagern, obwohl die von ihr genähten Kleider nur dort verkauft werden), wird zu Ende gehen. Die Reichen in dieser Welt (wir) beuten die Armen mehr in enormen Masse aus und die Anzahl der Sklaven ist höher als je zuvor in der Geschichte der Menschheit.

Die durch diese Gegensätze generierten Spannungen dürften sich wie Erdbeben entladen. Das beginnt schon jetzt. Die Verschlechterung der Rahmenbedingungen in vielen Regionen (Klima, Wasser, Ernährung und Böden) entwickelt sich geometrisch wachsend und wird uns früher oder später in kritische Bereiche bringen. Die Spannungen werden immer spürbarer.

So könnte es ganz schnell gehen, dass wir sehr unsanft aus unseren aktuellen Träumen geweckt werden. Meine Hoffnung ist, dass uns auch hier die Informatik helfen wird. Natürlich weiß ich aber noch nicht wie und kann mir dies nur so ungefähr vorstellen.

Ich glaube, dass die IKT einen positiven Beitrag für die menschliche Zukunft nur dann leisten kann, wenn es ihr gelingt, vor allem einen hochkomplexen, weltweiten, redlichen Diskurs zu unterstützen, der eindringliche Ergebnisse bringt. Nur so kann eine Konsensbildung gelingen, die nicht auf Feindseligkeit und Ausbeutung beruht sondern die Menschen (uns) auf und für die notwendige Veränderung von Denken und Leben vorbereitet.

Nur so kann die globale Gesellschaft mit möglichst wenig Gewalt verändert werden. Nur so kann die heutige Art des Wirtschaftens in eine „Gemeinwohl-Ökonomie“ transformiert werden. Und nur so können wir Lösungen für ein besseres Copyright- und Patentwesen finden. Durch die Weisheit der Vielen und gegen die Einfalt des Einzelnen.

[Hinweis: Unsere Kollegen von Youmigo.de haben das vielleicht verstanden und eine wunderbare APP zur „Weltverständigung“ geschrieben.]

Dem Artikel im TUM Magazin würde ich entgegen halten, dass wir keine Luxuswelt von vernetzter Technologie brauchen, die uns letztendlich noch mehr versklavt. Zu Werner Meixners Aussagen meine ich, dass er das Thema „pretty good privacy“ in Form eines Glaubensbekenntnis überhöht, dieses aber nicht glaubhaft begründet sondern im dogmatischen verbleibt.

Und ich meine, dass in Zukunft uns Menschen unsere Privatsphäre ziemlich egal sein wird. Weil wir ganz andere Probleme haben werden. Und wir Menschen uns immer im Spannungsfeld Individualität und Kollektivität bewegen werden. So oder so. Mit Datenschutz und ohne. Und das schaffen wir nur auf eine dem Menschen würdige Art, wenn wir auf Werte basiert denken und handeln. Dogmen und deren gebetsmühlenartige Verkündung hilft uns nicht.

Noch ein Satz zu den persönlichen Daten. Informationen über Menschen zu sammeln ist doch ein ganz normaler Teil der menschlichen Zivilisation, die sich ja aus guten Gründen Administrationen geschaffen hat und so z.B. die Geburt eines Kindes protokolliert. Natürlich hat der technologische Fortschritt seit der Erfindung von Karteikästen und -karten unglaubliches ermöglicht.

Sicher lässt sich mit „neuen“ Technologien viel mehr Daten sammeln als früher. Das ist aber nur die Fortsetzung einer Entwicklung, die begonnen hat mit der Erfindung von der Schrift und Papier als Möglichkeit, Informationen aufzuzeichnen und weiterzugeben. Mag sein, dass die Erfindung von Dateikasten und -Karten (sicher eine Erfindung von IT), einen Schub gebracht hat. Und die IKT dann nochmal.

Aber: Hat die IKT hier wirklich so viel verändert? Und wie groß ist der Schaden? Und ist es nicht wunderschön, dass Informationen generell durch Whistle-Blower veröffentlicht werden können und die IT dies noch viel leichter gemacht hat?

Ich sehe eine Bedrohung nur dann, wenn sich „unmoralische Systeme“ (wie z.B. ein Unrechtssystem) der Daten bemächtigen. Aber dann hilft uns auch kein Datenschutz. Vielmehr müssen wir vermeiden, dass wir unter die Kontrolle „unmoralischer Systeme“ geraten. Und das ist eine permanente gesellschaftliche Herausforderung für jeden Bürger. Der „Kommerziellen Nutzung“ von Daten zu widerstehen geht sowieso nur durch persönliche Autonomie, aber das war und ist mit der andauernden Manipulationsbedrohung durch Marketing genauso. Und wenn man unsinnig konsuminert, kostet das doch nur Geld und selten das Leben.

Persönlich empfinde ich den vermeidbaren Schaden, den uns die „alten“ Technologien der letzten 100 Jahre zugefügt haben und heute permanent zufügen, deutlich höher als den Schaden, den die neue Technologie IKT in den letzten 25 Jahren generiert hat.

Die Technologien des letzten Jahrhunderts haben uns zum Beispiel die Ruhe geraubt. Wer kennt noch einen Ort in München, der frei von „technischem Rauschen“ ist? Die Lärmverschmutzung ist jedoch ein wirklich harmloses Beispiel im Verhältnis zu anderen Folgen wie den 1,2 Millionen Verkehrstoten pro Jahr – weltweit verursacht durch den motorisierten Individual-Verkehr. Und die wir auch sonst nur zu gut kennen aber gerne ignorieren wie den Kohlendioxid-Gehalt in der Atmosphäre.

So wie wir uns an die grenzenlose Lärm-Emissionen gewöhnt haben, so haben wir uns doch schon lange unsere (ja trotz allem immer nur sehr eingeschränkte) Transparenz akzeptiert. Eingeschränkt, weil auch die vernetzen Systeme der Industrie und Welt 4.0 kaum unsere Gedanken lesen werden können. Und weil wir uns eh zu autonomen Menschen in einem selbstbestimmten kollektiven Rahmen entwickeln müssen, wenn wir überleben wollen.

Sind so gesehen die permanenten Forderungen nach Geheimhaltung von Daten nicht nur ein Protestschrei, weil man ja gegen irgendwas sein will und muss, sich aber nicht traut, gegen die wahren Bedrohungen aufzustehen?

Aber vergessen wir nicht:

Nur die neuen Technologien bieten uns die Chance, uns zu vernetzen und unsere Gedanken zu veröffentlichen. Und so gegen Ignoranz, Intoleranz, Dogmen, Unvernunft und Dummheit und manches mehr dieser Art zu wehren.

RMD

Auf der InterFace 30 Jahre Feier war Gerhard Saeltzer einer unserer Ehrengäste. Als „Überraschungsgast aus Dresden“ hatte er eine wunderbare Rede vorbereitet. Im Trubel und Lärm des Festes fand sich leider keine Gelegenheit, dieser Ansprache den angemessenen Rahmen zu geben. Die Rede beschreibt im ersten Teil ein beeindruckendes Kapitel deutsch/deutscher Geschichte, an dem die InterFace und ich sehr früh teilhaben durfte.

Schön, dass es Euch alle gibt!

Lieber Roland Dürre, liebe InterFace’ler, liebe Gäste!

Heute feiern wir gemeinsam den 30. Geburtstag von InterFace. Für die Einladung danke ich herzlich und bin gleich aus dem fernen Dresden mit meiner Frau hierher geeilt

Schön, dass es Euch alle gibt und dass wir uns alle hier zusammengefunden haben!

Erinnern wir uns an Ereignisse, die 24 Jahre zurückliegen, an das Jahr der Deutschen Wiedervereinigung 1990. Was waren das für spannende und aufregende Zeiten! Und was für frustrierende Zeiten im Osten! Da kamen z.B. zu uns nach Sachsen Deutsche aus Bayern mit einer für unsere sächsischen Ohren so ganz anderen Sprache. Und das zweite Wort, was die Bayern von sich gaben, war eins, was im Osten ausgemerzt worden war: Gott. Überall hörte man „Grüß Gott“ – was die Sachsen nur verlegen und kleinlaut mit einem „Na goodden Taach“ erwidern konnten.

Und wir lernten, dass mit dem göttlichen Gruß auch etwas ganz anderes kam: Die Kirchensteuer übers Finanzamt und häufig schockierend hohe Nachzahlungen für die Ostler. Und dann geschah ganz Erstaunliches: In den Osten strömten scharenweise besondere Ritter – Glücksritter und Raubritter. Dazu überkluge Juristen und Politiker, Berater und Makler, die Funktionäre und Gewerkschaftler, darunter viele, die – sagen wir es deutlich – im Westen überflüssig oder ausgemustert waren. Da rückten im Eiltempo heran die Abzocker: Die Autohändler, die vierrädrigen Schrott als Neuwagen verkauften. Die Textilhändler, die gebrauchte Kleidung als neu verkauften. Die flinken Immobilienjäger, die große marode Ost-VEB‘s für 1 DM kauften, abwickelten und dann die Grundstücke für Millionen verkauften. Und die Vertreter für alles Mögliche und völlig Überflüssige, vor allem Versicherungen. Auch ich habe davon unnötig „genascht“.

Ich lernte im Osten tolle Juristen und Beamte aus dem Westen kennen, die z.B. nicht einmal wussten, dass man eine Klage unterschreibt – bevor man sie beim Gericht einreicht. Und es kamen sogar Showmaster und Zauberer. Einer landete sogar direkt aus dem Himmel – mit einem geborgten Hubschrauber – in Dresden, wie ein Glücksgott. Er baute in einem Sumpfgebiet eine neue Vorstadt von Dresden, verkaufte die besten Fußballspieler und verschwand letztlich hinter Gittern. Und es kamen auch tolle IT-Berater, die von Tuten und Blasen keine Ahnung hatten und nicht einmal wussten, was Software-Engineering und Softwarequalität ist.

Ja, liebe Bayern, so gab es damals nach der Wende im Osten reichlich Frust und negative Kulturschocks. Wir mussten uns total umprogrammieren. Und dann geschah plötzlich ein Wunder, ich erlebte das Umgekehrte, eine Art positiven Kulturschock. Ich lernte in Dresden den Unternehmer Roland Dürre mit Teilen seiner jungen Mannschaft, seine Frau und sogar seinem jüngsten Sprössling Rupi, näher kennen.

Einen Mann, der so ganz anders war. Ein Unternehmer, der nicht nur groß schwätzte, sondern etwas von seiner Sache verstand, mit dem man reden konnte, von Mensch zu Mensch, ohne Arroganz – sondern partnerschaftlich, der nicht erst den Inhalt meines Portmonees prüfte (indem ich sowieso nichts hatte), bevor er mit mir redete. Und der sogar als Präsident ganz familiär in Filzpantoffeln seine Mitarbeiter aufsuchte. Mit einem sportlich bescheidenen Lebensstil, der zur der täglichen Körperpflege Kernseife aus Armeebeständen gewissen parfümierten Chef-Seifen vorzog. Roland Dürre, der Unternehmer, der so aufmerksam zuhören konnte, ein Mann mit dem das Gespräch, die Zusammenarbeit, Teamarbeit richtig Spaß machte, ein flexibler Teamplayer im besten Sinne.

Ich sage es frei heraus: Roland Dürre und sein Team kamen mir als Wende-frustrierten vor wie Außerirdische von einem anderen, positiven Stern. Und Sie haben erfolgreich die letzten 30 stürmischen Jahre gemeistert! Ich bewundere alle Beteiligten von InterFace.

Ihr seid einfach Klasse! Schön, dass es Euch alle noch gibt!

Herzlichen Dank InterFace und Roland Dürre für diesen erlebten Lichtblick, diesen positiven deutsch-deutschen Nach-Wende-Kulturschock! Lieber Roland Dürre! Wir waren damals beide verwegen und mutig und organisierten die erste deutsch-deutsche Fachtagung für moderne Software und Anwendungssysteme SoftSys 9/90 in Dresden. Wir waren beide – mit unseren bescheidenen Ressourcen – sogar schneller als die großmächtige Politik.

Schon 9 Tage vor der Wiedervereinigung, am 3.10.1990, fand unsere Ost-West-Deutsche Wiedervereinigung als Fachtagung in Dresden statt! Gute Kommunikation zwischen uns zeigte deutlich messbare Wirkung: Es lief alles schneller. Die Verbindung zwischen uns riss leider ab.

ComputerweltUmso wunderbarer war es, dass wir uns nach 24 Jahren plötzlich wieder fanden. Ich fand InterFace im Internet, als ich nach mir selbst suchte und zufällig eine Buchbesprechung über mein Informatikbuch für Kinder und späteres Schulbuch in Sachsen „Erstaunliche Computerwelt“ entdeckte.

Lieber Herr Dürre, liebes InterFace Team!

Wenn ich so zurückblicke, bin ich etwas traurig: In Deutschland und Europa gibt es gegenwärtig zu wenige, leider viel zu wenige Unternehmen mit einer so angenehmen, kommunikativen und fairen Kultur wie InterFace. In diesen Zeiten der Firmen-Insolvenzen und -Übernahmen bewiesen, wo so manches Unternehmen den Bach hinunter ging, konntet Ihr Euch erfolgreich am Markt behaupten. Wunderbar! Viele können von Euch lernen.

Ich bewundere Euch!

Es ist wirklich schade, dass die Wissenschaft heute etwas Wichtiges noch nicht beherrscht. Das perfekte Klonen. Es würde Deutschland und Europa und der Welt besser gehen, wenn man Sie und Ihr Unternehmen klonen würde, sagen wir 5mal oder etwas unbescheidener 20mal! Und weil das leider noch nicht klappt, müsste man wenigstens ganz schnell ein Denkmal oder wenigstens eine Denktafel für InterFace hier in Unterhaching setzen. Auch wenn es noch nicht so schnell klappt: Wenigstens schnell noch meine herzlichen Glückwünsche, etwas angelehnt an Theodor Fontane:

„Kummer sei lahm! Sorge sei blind!
Weiter 30 gute Jahre in bester Gesundheit
wünschen wir dem Geburtstagskind!“

Und lieber Roland Dürre, noch eine kleine Bitte für die Zukunft – weil Zusammenarbeit mit Ihnen so großen Spaß macht, habe ich eine hübsche Idee für ein neues gemeinsames Projekt mit weltweitem Wirkungspotential mitgebracht. Doch darüber möchte ich noch gerne mit Ihnen reden.

Allen wünsche ich beste Gesundheit und viel Glück auf allen Wegen!

Grüß Gott! Godden Taach, und bis bald – vielleicht in der Session mit heiteren Anekdoten aus meinem Leben mit dem Computer im Osten! Herzlich lade ich alle ein!
Dr. Saeltzer, Unterhaching am 27.6.2014

Hochzeit im FlußDie Einladung erging zur Session „Faszinierendes und Anekdotisches rund um Gegenwart und Zukunft der Computeranwendung“ von Dr. Saeltzer auf unserer 30 Jahre Feier. In dieser Session berichtete er lustige Anekdoten vom Start der IT in der DDR in den sechzigern Jahren. Er betätigte sich auch als Mutmacher und zeigte mit kleinen Lesungen aus seinem Buch „Hochzeit im Fluss“ (einer „Anleitung zur Resilienz) wie Menschen selbst in schwierigen Situationen wie bei der Dresdener Hochwasser-Katastrophe Zuversicht bewahren können.

Beim Lesen dieses Textes habe ich rote Ohren bekommen, mich aber umso mehr sehr gefreut.

Einen ganz großen herzlichen und lieben Dank an Dr. Saeltzer.

RMD

P.S.
Ein paar Stichworte zu unserem „Überraschungsgast“ Dr. Gerhard Saeltzer:
Informatiker, Softwaretechnologe und Simulationsexperte, Autor, Dozent, Trainer (über 10 Bücher, auch ein Bestseller, 100 gedruckte Fachbeiträge, 1000 Vorträge und Kurse, Exposees für das Bildungsfernsehen), ganzseitige Auftritte und Interviews in der Tagespresse, Chairman großer Fachtagungen im Osten, Erfinder von Innovationen wie ProgFox, LEMA, zuletzt angestellt in der Position eines Regierungsdirektors beim Sächsischen Datenschutzbeauftragten in Dresden, jetzt im Unruhezustand, joggt in Dresden seit 45 Jahren täglich 20 Minuten zwischen 6:00 und 9:00 Uhr.

P.S.2
Der Text ist original von Dr. Gerhard Saeltzer. Die Bilder der beiden genannten Bücher habe ich eingefügt.

Roland Dürre
Dienstag, der 8. Juli 2014

Bernhard Findeiss – Kanban oder Scrum

Ein zweiter Vortrag von unserem fachlichen IF-Forum

“Selbstorganisation als Gestaltungsmodell für Unternehmen”

am 27. Juni 2014 ist jetzt frei verfügbar (creative commons – Namensnennung).

Viel Spaß beim Anschauen!

Einen großen Dank an unseren Referenten Bernhard Findeiss!

Ich gehe davon aus, dass ich jetzt jeden Tag einen weiteren Vortrag veröffentlichen kann. Dafür großen Dank an Friedrich (Friedrich Lehn).

RMD

Gerade habe ich mir ein wenig die Hintergründe zum SSL/TLS-Bug durchgelesen, der Apple diese Woche ereilt hat.

Wer grad nicht weiß, wovon ich spreche, hier ein paar Links:

Heise.de: „Ein Sicherheitsdesaster“: Hintergründe zu Apples schwerwiegendem SSL-Problem
Golem.de: iOS erhält SSL-Bugfix, OS X bald auch
Spiegel.de: Sicherheitslücke: Apples furchtbarer Fehler

Interessant dabei ist, daß dieser Bug nur auf eine einzige Code-Zeile hinausläuft. Er wäre einfach zu verhindern gewesen, hätte man die grundlegenden Regeln von „Clean Code“ befolgt.

Hier der Code-Auszug, der den Fehler beinhaltet. Ich habe ihn von Apple selbst, da der entsprechende Code unter einer OpenSource-Lizenz steht (siehe hier).

hashOut.data = hashes + SSL_MD5_DIGEST_LEN;
hashOut.length = SSL_SHA1_DIGEST_LEN;
if ((err = SSLFreeBuffer(&hashCtx)) != 0)
goto fail;


if ((err = ReadyHash(&SSLHashSHA1, &hashCtx)) != 0)
goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &clientRandom)) != 0)
goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
goto fail;
goto fail;
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
goto fail;

Warum ist nun aber genau dieser Code problematisch?

Schon gesehen?

Ich gebe zu, auch bei mir hat es ein wenig gedauert. Ich versuche es mal zu erklären:

Normalerweise ist es in der Programmiersprache C (in der dieser Code geschrieben ist) der Brauch, Anweisungen nach einem „If“-Statement in geschweifte Klammern zu setzen. In etwa so:

if (bedingung) {
Anweisung 1;
Anweisung 2;
Anweisung 3;
...
}

Es gibt jedoch die Möglichkeit, auf die geschweifte Klammer zu verzichten, wenn hinter der Bedingung nur eine einzige Anweisung folgt.

Also so:

if (bedingung)
Anweisung 1;

In diesem, zweiten Stil, sind auch alle „If“-Statements aus dem Code-Auszug von Apple geschrieben. Der Programmierer wollte sich so wohl einige Zeichen Tip-Arbeit sparen. Dummerweise hat sich aber nun ein kleiner Fehler eingeschlichen: Nach dem rot markierten If-Statement steht nicht eine, sondern 2 Anweisungen.

Was passiert nun in so einem Fall?

Nun, der Compiler wertet die Regel strikt aus: Steht hinter einem If-Statement keine Klammer, so folgt genau 1 Anweisung: Die erste Anweisung (in diesem Fall „goto fail;“) gehört also noch zum If-Statement. Die zweite Anweisung gehört für den Compiler jedoch nicht mehr zum If-Statement. Sie wird daher in jedem Fall ausgeführt. Ganz so, als sähe der Quellcode so aus:

if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
goto fail;

goto fail;

if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
goto fail;

Das zweite „goto fail;“ wird daher in jedem Fall ausgeführt, und damit die Textmarke „fail“ bereits angesprungen, bevor das letzte, blau hinterlegte if-Statement ausgeführt werden kann.

Was hat das nun aber mit Clean Code zu tun?

Aus meiner Sicht ist es kein guter Stil, in if-Statements auf die geschweifte Klammern zu verzichten. Zu welch schwerwiegenden Problemen das führen kann, sieht man z.B. genau mit diesem Beispiel hier. Besser ist es, man verwendet geschweifte Klammern, dann ist es auch eindeutig, was ausgeführt wird und was nicht. Wahrscheinlich hätte hier dann sogar der Compiler davor gewarnt, dass das zweite „goto fail;“ nicht erreicht werden kann („Dead Code“), und damit überflüssig ist.

So jedoch hatte der Compiler keine Chance. Auch die ganzen Tools zur statischen Quellcodeanalyse, die Apple sicherlich im Hintergrund anwendet, laufen hier ins Leere. Und die Wahrscheinlichkeit, daß ein anderer Programmierer das zufällig entdeckt, wenn er drüberschaut, ist ebenfalls nicht allzu hoch: Der Fehler ist gut versteckt. Man muß schon mehrmals hinsehen, um ihn zu entdecken.

Was kann man nun dagegen machen?

Die einfachste Methode ist es, sich solche „besseren“ Schreibweisen gar nicht erst anzugewöhnen, sondern beim Standard zu bleiben. Die meisten IDEs bieten dafür sogar Regeln an, die man hinterlegen kann. Dadurch werden entsprechende Code-Stellen als Warnung oder sogar als Fehler hinterlegt. Rutscht doch einmal eins durch, so wird es bei der automatischen Code-Formatierung (dessen Tastenkombination man während der Entwicklung ständig drückt) wieder in die Standard-Schreibweise aufgelöst.

Es ist eine gute Idee, einmal einen kompletten Satz solcher Code-Formatierungsregeln zu definieren, und dann anschliessend an alle Teammitglieder zu verteilen.

Man kann dies sogar so einstellen, daß es automatisch an alle verteilt wird, die das Projekt aus dem Versionsverwaltungssystem auschecken. Z.B. indem man etwa projektspezifische Regeln anlegt, und diese in ein Verzeichnis innerhalb des Projekts legt.

Sollten Sie das bisher noch nicht gemacht haben, so ist es eine gute Idee, nun damit anzufangen.

Ich kann mir vorstellen, bei Apple sind sie gerade voll dabei  😎

bfi

Roland Dürre
Freitag, der 14. Februar 2014

Ultimative Qualität für Software!

Das Bewusstsein für die Relevanz von „Software“ als kritischer Faktor für den Unternehmenserfolg ist gestiegen. Auch in Deutschland richten jetzt große Konzerne ihr Augenmerk immer mehr auf ihre IT-basierenden Anwendungen und untersuchen gezielt die Qualität derselbigen um sie dann zu verbessern.

Mir stellen sich – mal völlig ungeordnet – ein paar Fragen:

  • Warum gibt es immer noch so große Software-Projekte mit 100 und mehr Programmierern?
  • Wieso glaubt man immer noch, man könne durch hohe Spezialisierung (Requirement Engineering, Architektur, Qualität, Implementierung, Konfiguration oder Projekt Management …) und Arbeitsteiligkeit in globalen Entwicklungs-Dreiecken wie Indien-USA-Europa erfolgreich und kostengünstig entwickeln?
  • Wieso lernt das Management aus den zahlreichen Fehlschlägen und Krisen bei so vielen IT-Projekten nichts?

Hier ein paar Antworten und Thesen, wie man es besser machen könnte:

  • Konzentration auf die Zukunft!
    Um Qualität zu schaffen und so wirklich wertvolle Software zu gewinnen würde ich mich zuerst mal auf die neuen Software-Projekte in den Unternehmen  konzentrieren. Das ist an sich schon eine große Herausforderung. Die „alten“ Applikationen würde ich nur soweit anfassen, wie dies unbedingt notwendig ist (es sei denn, ich verfüge über zu viel Ressourcen und Geld). Denn zu groß sind hier in der Regel organisatorische, systemische und menschliche Widerstände, so dass jede hier erzielte Verbesserung sehr teuer erkauft ist.
    Bei neuen Projekten dagegen kann ich zumindest projekt- und methodentechnisch auf grüner Wiese starten und in aller Strenge dafür sorgen, dass falsche Strukturen und Entwicklungen erst gar nicht entstehen.
  • Das Können der Mitarbeiter ist alles!
    Ich habe jetzt in über 30 Jahren Erfahrung in SW-Entwicklung gesammelt und immer wieder erlebt, dass nur ein Viertel bis maximal ein Drittel der Menschen, die als Programmierer in den Projekten arbeiten – ganz gleich mit welchen Titeln und Zertifikaten versehen – in der Lage sind, ultimative Qualität abzuliefern. Von den verbleibenden zwei Dritteln sehe ich bei vielleicht der Hälfte das Potential einer gewissen Verbesserung durch intensive Ausbildungs- und Trainingsmaßnahmen. Der Rest wäre besser nie Programmierer geworden. Dieses Verhältnis ist nach meiner Beobachtung in den letzten Jahren nicht besser sondern schlechter geworden. So tummeln sich viele nicht so gut ausgebildete und/oder talentierte Programmierer eifrig in übergroßen Projekten herum und verstecken sich dort in der Masse.
    Ich will damit keinesfalls einen Berufsstand schlecht machen. Ich brauche aber in der Software-Entwicklung durchgängig Ergebnisse mit einer „ultimativen Qualität“. Und die wird in der Tat nur von einem recht kleinen Teil der in den Projekten tätigen Programmierern erbracht.
    Bei „Architekten“ oder „Requirement Engineers“ dürfte die Quote der wirklich qualifizierten noch geringer sein als bei den „Implementierern“, was die Software-Entwicklung noch kritischer macht.
    Die Zahlen sind übrigens bei anderen Branchen nach meinem Eindruck nicht viel anderes. So habe ich auch bei „Handwerkern“ bemerkt, dass in der Regel nur ein Drittel ihren Job so beherrschen, dass qualitativ wirklich gute Werkstücke herauskommen. Und auch da hätte zirka ein Drittel besser einen anderen Beruf gewählt.
    Bei dem Aufbau eines neuen Teams dürfen also nur Kollegen ins Projekt aufgenommen werden, die ihr Handwerk wirklich beherrschen. Das gilt für alle Rollen, diese Selektion ist alles andere als einfach, das ganze viel leichter gesagt als getan – denn zu oft muss man „NEIN“ sagen. Obwohl man dringend Leute braucht. Aber Kompromisse gerade hier rächen sich in der Regel bei der Qualität der Ergebnisse. Und wenn man nur die „guten“ nimmt, dann braucht man viel weniger …
  • Kommunikation
    Die Kommunikation im Entwicklungsteam wie zwischen allen Beteiligten im Projekt muss funktionieren! Wie soll das gehen, wenn in vielen Projekten schon gar keine gemeinsame Sprache mehr gesprochen wird? Oder wenn zwar alle Englisch sprechen, jeder dabei aber sein „eigenes Englisch“ dabei hat, das der andere kaum versteht?
    Wichtig ist hier die Anzahl von Meetings stark zu begrenzen. Die Meeting-Flut muss eingedämmt werden. Denn der Nutzen von Meetings sinkt mit der Anzahl von Personen, die teilnehmen und der Länge der Zeit, die sie dauern. Der Schaden steigt in gleichem Maße an. Eine Lösung dieses Dilemmas ist eine Organisation von Kommunikation durch sinnvolle „peer2peer“-Mechanismen.
  • „Requirement Engineering“
    Der Versuch, Anwendungs-Software präzise und komplett vor der Implementierung zu beschreiben, hat noch nie zu optimalen Ergebnissen geführt. Immer stellt sich bei solchem Vorgehen heraus, dass dann vieles Unnötiges gebaut wird und dafür aber wesentlich Notwendiges fehlt. Die Folgen sind aufwendige und oft zu implementierten Funktionen widersprüchliche Change Requests. So hängt der Erfolg eines jeden Projekts wesentlich von der Qualität der Person oder den Personen ab, die den „Product Owner“ ausmachen.
    Gute Product Owner wissen nie alles im Voraus, sondern lernen im Entwicklungsprozess laufend dazu. Ein iterativer und agiler Prozess des „Requirement Engineerings“ ist zwingend notwendig. Bei neuen Projekten empfiehlt es sich hier in „user stories“ zu denken und dann (begrenzt) die dazugehörigen „use cases“ zu beschreiben. Das kann aber nur gehen, wenn die Architektur flexibel ist.
  • „Flexible Architektur“
    Aufgrund des Lernprozesses der Product Owner und der sich iterativ verändernden Funktionalität wird eine offene und belastbare Architektur zur zentralen Voraussetzung für den Erfolg eines Projektes. Das erhöht die Anforderung an die Architekten aber auch den Anspruch an die Kommunikation zwischen „Product Owner“ und „Architekten“ und letzten Endes dem ganzen Team. Die beiden letzten Punkte gelten nach meiner Meinung übrigens auch nicht nur für Software-Projekte.
  • Geisteshaltung
    Die Geisteshaltung streift viele Dimensionen. So müssen alle Projektteilnehmer sich vom ersten Tag einem ultimativen Qualititätsanspruch verpflichten. Sie müssen verstehen, dass sie Qualität in aller erster Instanz für sich selber schaffen. Eine gemeinsame Projektvision muss vorhanden sein. Die Zusammenarbeit muss auf Augenhöhe und gegenseitigem Respekt erfolgen, Politik im Projekt ist ein NOGO. Qualitätssichernde Maßnahmen wie Peer2Peer-Reviews werden zum Standard, Meetings extrem kurz und selten stattfinden und sich auf zwingend notwendige Abstimmungsprozesse beschränken. Dafür kann dann gerne mal öfter der Erfolg gefeiert werden.
    Unnötiger bürokratischer Aufwand ist ein weiteres NOGO, eine „gute“ Projektkultur macht Bürokratie überflüssig. Das Projekt und sein Status sind immer für alle transparent, „Insider“-und „Herrschafts-Wissen“ wird zur Ausnahme. Auf unnötige Aufwände für „estimate“ und „planning“ wird soweit möglich verzichtet!
  • Verantwortung
    Die Projektteilnehmer dürfen sich nie auf eine Verantwortungs-Rolle reduzieren. Jeder muss in der Lage sein, „hands on“ anzulegen. Jeder ist zu einem – vielleicht auch nur kleinen Teil – für alles verantwortlich, für Requirement Engineering, Projektsteuerung, Architektur, Qualität, Integration, Konfiguration und Implementierung. Jeder muss mithelfen, unnötige Hürden für freie Kommunikation zwischen allen zu reduzieren. Das gilt für alle, denn alle sind für den Projekterfolg verantwortlich, entsprechend ihrer Qualifikation und Rolle dies natürlich auf unterschiedliche Art und Weise.
  • Craftsmanship
    Und alle Beteiligten müssen sich ständig in ihrem Handwerk üben. Sie müssen bereit sein „vom Meister zu lernen“ und ihre besondere „Meisterschaft“ zu vermitteln, sprich auch ihr Können weiterzugeben und ihr Wissen zu teilen.

Wenn diese Bedingungen erfüllt sind, können auch überschaubare Teams Unglaubliches  sowohl in Qualität wie auch funktionaler Quantität leisten. Der oft unnötige Overhead der großen Teams fällt weg. Und die Verwunderung beim Management ist groß, dass ein Zehn-Mann-Team etwas schafft, an dem ein Team mit einer Hundertschaft vorher gescheitert ist.

RMD