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!

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
Mittwoch, der 26. Juni 2013

Bernhard Findeiss und Dr. Elmar Jürgens im IF-Forum (Video)

Das Kunstwerk von Wolf Nkole Helzle, entstanden bei unserem IF-Forum CRAFTSMANSHIP habe ich schon als „Danke Schön“ veröffentlicht. Auch die ersten beiden Vorträge des IF-Forums von Wolfgang Menauer und Kristin Block konnte ich vor ein paar Tagen „live“ stellen.

Heute folgen die beiden nächsten!

Zuerst sehen wir Bernhard Findeiss, „Technologie Evangelist“ bei der InterFace AG. Er berichtet „Von einem Tag im Leben eines Software-Handwerkers“:

Dr. Elmar Jürgens von CQSE berichtet über seine eigene Erfahrungen und die guten Ergebnisse im Team mit Peer2Peer-Reviews im Dienste der Qualität:

Vielen Dank an die beiden Referenten und Friedrich Lehn, der für die Aufnahme und Produktion der beiden Videos verantwortlich war.

Jetzt fehlen nur noch die Vorträge von Bernd Fiedler und Reimund Büttner. Aber die kommen auch bald!

RMD

Roland Dürre
Donnerstag, der 13. Juni 2013

Heute: Fachliches IF-Forum bei InterFace in Unterhaching ab 13:00!

IF20x_5172Heute ist es wieder soweit!

Ab 13:00 startet unser Workhop „Craftsmanship“!

Alle Informationen finden Sie hier!

Es sind noch ein paar Plätze frei!

Und für all die, die nicht kommen können, übertragen wir den Vortrag wieder live im Internet.

Unter http://www.ustream.tv/channel/IF-Forum kann man ab ca 13:45 den Video-Stream zum Vortrag sehen.

Zusätzlich zur Übertragung werden wir wie immer einen Video-Mitschnitt anfertigen und auf youtube (Kanal InterFace AG) zur Verfügung stellen.

RMD

Roland Dürre
Samstag, der 11. Mai 2013

Referent bei Craftsmanship: Dr. Elmar Jürgens im IF-Forum

Dr. Elmar Jürgens ist einer der Referenten unseres Workshops Craftsmanship am 13. Juni. Sein Vortrag wird den Titel haben:

Wissenstransfer durch leichtgewichtige Reviews
Erfahrungen aus 6 Jahren Einsatz in einem heterogenen Team

Hier ist der „Abstract“ seines Vortrages bei uns:

Erfahrung, Können, Kultur, Qualität und Wissen stehen im Zentrum des IF Forums zu Craftsmanship. Wie können wir in der Entwicklung von Software eine Kultur schaffen, die gegenseitigen Austausch von Erfahrung, Können und Wissen so fördert, dass die Qualität unserer Software profitiert?

Für mich ist die Antwort eine Kultur von leichtgewichtigen Peer-Reviews. Es gibt kaum eine Qualitätssicherungstechnik, deren Nutzen ausführlicher untersucht und besser belegt wurde, als Peer Reviews. Sie bieten außerdem ein effektives Werkzeug des Wissenstransfers. Wir setzen sie seit Jahren erfolgreich ein. Trotzdem führen viele Teams keine entwicklungsbegleitenden Peer-Reviews durch.

In diesem Vortrag stelle ich einen leichtgewichtigen Ansatz für kontinuierliche Code-Reviews vor, bei dem Programmierung und Review voneinander entkoppelt sind. Programmierer und Reviewer können dadurch selbst bestimmen, wann, wo und wie schnell sie arbeiten. Bei der Entwicklung des Open-Source Programmanalysewerkzeugs ConQAT setzen wir diese Reviews seit 7 Jahren zur Qualitätssicherung aller Code-Änderungen ein. Freiwillig. Wir sind überzeugt, dass sie der Hauptgrund für die Wartbarkeit und Flexibilität von ConQAT sind. Ich stelle unsere Erfahrungen vor und gehe dabei auch auf soziale Herausforderungen und Best Practices ein.

Zur Person:

Dr. Elmar Jürgens ist Gründer und Gesellschafter der CQSE GmbH. Elmar promovierte an der Technischen Universität München über Erkennung, Auswirkungen und Umgang mit Klonen und erhielt dafür 2011 den Software-Engineering-Preis der Ernst Denert-Stiftung. Als Mitgründer der CQSE GmbH unterstützt er Unternehmen bei der Analyse und Verbesserung der Qualität ihrer Softwaresysteme. Auf den Software Quality Days 2013 wurde er unter die fünf besten Referenten gewählt.

Des weiteren ist Elmar der Co-Chair des International Workshops on Software Clones, der in diesem Jahr am 19. Mai in San Francisco im Rahmen der „International Conference on Software Engineering“ stattfindet.

Elmar hat auch eine ganz besondere Community begründet: Mit Doktoranden der TUM und Kollegen der CQSE GmbH veranstaltet er regelmäßig eine „Tasting Group“. Bei jedem Meeting „probiert“ die „Tasting Group“ eine Idee (in Form eines etablierten Forschungspapiers im Bereich Software Qualität) und einen Geschmack (z.B. in Form einer Weinprobe oder eines Test von besonderer Küche). Das empfinde ich wahrlich als ein innovatives Konzept!

RMD

Roland Dürre
Mittwoch, der 16. Januar 2013

Wissen und Spaß für Informatiker

Am 17. Januar 2013 startet eine neue Vortragsreihe im Rahmen von IF-Lab und IF-Akademie bei InterFace in Unterhaching.

Thomas Baldus von IF Blueprint AG eröffnet morgen um 18:00 (InterFace Schulungszone im Dachgeschoß) mit dem Thema:

APPetit auf Microsoft?!
Wie sieht die neue Geschmacksoffensive aus, die über den Teich geschwappt kommt?

Alle Informationen zur Vortragsreihe findet man im IF-OPEN. Ganz wichtig – es geht nicht nur um den Vortrag, sondern besonders um das „sich Treffen“ im Rahmen eines modernen Vortragsformats mit anschließender „Happy Hour“.

Ich freue mich auf viele Besucher. Und suche auch Referenten, die gerne ihr Wissen weitergegeben wollen, für die weiteren Termine. Mit dem Motto:

Aus der Praxis für die Praxis.

Oder auch:

Informatik & Bier

RMD

Bernhard Findeiss
Dienstag, der 25. Oktober 2011

Handwerklich gut gemachte Software – für viele ein zu hoher Anspruch?

In den letzten Monaten habe ich mich zusehends mit Software Craftsmanship beschäftigt.  Eine der spannendsten Thesen darin ist die Forderung:

„Not only working software, but also well-crafted software“ (siehe hier).

Hinter diesem so einfach klingenden Satz verbirgt sich für mich ein Thema mit einigem Diskussionspotential. Natürlich ist eine funktionierende Software immer besser als ein Schrank voller Ordner mit Spezifikationsdokumenten auf totem Baum.

Jedoch gehen bereits die Vorstellungen darüber, was man unter „funktionierender Software“ zu verstehen hat, teils weit auseinander: Der einfachsten Definition nach würde es bereits ausreichen, einen kompilierfähigen Quellcode zu haben. Doch reicht das schon? Besser wäre es, den Quellcode vor der Auslieferung nicht nur zu kompilieren, sondern auch tatsächlich mal laufen zu lassen. Zudem besteht zumindest die entfernte Möglichkeit, daß die allererste Version der Software evtl. nicht der ganz große Wurf ist. Insofern wäre es auch nicht schlecht, sich zumindest im Grundsatz schon mal Gedanken zu den Themen Lesbarkeit, Wartbarkeit und Erweiterbarkeit zu machen.

mehr »