Tag Archives: office

IT explained

sclable: Das “rapid everything” ERP

Vergangene Woche hatte ich das Vergnügen, an einer sneak peek für ein überraschend neuartiges ERP-System teilzunehmen. Das Wiener Startup sclable tritt an, um das SAP oder Oracle von morgen zu werden. Die Ansage ist natürlich zu stark, um zu halten, aber dennoch ist das Produktkonzept mehr als nur einen Blick wert.

Ich würde sclable als Scaffolding Framework mit Workflows und hübschem UI beschreiben. Sagt vorerst wenig: Man kann damit jedenfalls sehr schnell individuelle Workflows in Software gießen und bleibt überdies flexibel. Es klingt ein wenig nach Heiligem Gral der Softwareentwicklung: Vorteile von Standard- und Individualsoftware vereint in einer Lösung, das Ganze durch geschulte Mitarbeiter in Eigenregie durchführbar.

sclable besetzt mit dieser Idee eine – zumindest für mich – komplett neuartige Nische im Unternehmen irgendwo zwischen zur Unhandhabbarkeit gewachsenen Excels, dem von Haus aus unhandhabbaren Sharepoint, der schwerfälligen Business Class mit SAP Workbench oder Oracle Forms sowie der Plugin-Architektur von WordPress.

Bereits nach der kurzen Einführung würde ich mir zutrauen, beispielsweise einen Bestellworkflow für ein mittleres Unternehmen mit sclable innerhalb weniger Stunden umzusetzen. So schnell, wie ich in sclable editiere, kann ich beim besten Willen nicht programmieren.

hgd
sclable at its best: Im Handumdrehen erstellte Entitäten werden mit beliebig komplexen Workflows verknüpft. Die graphische Darstellung ist bereits der halbe Weg zur Dokumentation.

Damit kommen wir zum wirklichen Vorteil: Durch die enorme Geschwindigkeit wachsen Spezifikation, Umsetzung, Test und Dokumentation zusammen. Es ist also vorstellbar alle Präsentationen, Powerpoints, e-Mails und Telefonate zu skippen und gleich gemeinsam mit dem Kunden loszulegen. Solange also die Aufgabenstellung zum Kern von sclable passt (“Mehrbenutzer-Workflow rund um ER-Modell”), ist’s ein Wahnsinns-Tool.

“Don’t ever fight a framework!”

Den Punkt, wo Customizing zur Vergewaltigung wird, darf man allerdings – wie bei jedem anderen Framework auch – nicht übersehen. Dann endet man schließlich wiederum in der Individualentwicklung, und hier würde ich dann generell zu Python/Django greifen. (Nun ja, da greife ich fast immer hin.)

Was paranoide oder Policy-geplagte CIOs beruhigen dürfte, ist außerdem die Info, dass das Produkt nicht nur als SaaS sondern auch on-premise laufen soll. Dank API sind Daten außerdem exportierbar, was langfristige Abhängigkeiten ohne Ausweg unterbindet.

Nachteil ist womöglich PHP als Runtime. Technisch ist es einfach pfui wegen fehlender Namespaces einer besch*** Standard Library, Patch-Wahnsinn, usw. Entwickler gibt’s jedoch genug. (Und mit Wikipedia oder Facebook gibt’s zugegebenermaßen ziemlich große PHP-Projekte, wo auch niemand über die Programmiersprache schimpft…)

Ich bin gespannt auf den Launch und weitere News von sclable.at!

Edit: Markus Nenning hat mich darauf aufmerksam gemacht, dass ERP eine nicht ganz korrekte Schublade für das Produktkonzept ist. Ich hab’s dennoch beim Titel belassen, da man sich mit bekannten Kategorien einfach leichter tut. Aber klar, mit der Flexibilität von sclable könnte man auch ganz andere Schubladen füllen – von Projektmanagement über CMS bis hin zu einem Universitätsverwaltungssystem.

IT explained

Gutes Office, schlechtes Office

Ich schimpfe an dieser Stelle immer wieder einmal über Office-Dokumente, weil sie meist zwar leicht zu erstellen, beinahe immer aber schwer zu pflegen sind. Insbesonders dann, wenn

  • Daten oftmals aktualisiert werden müssen,
  • mehrere Personen diese Änderungen durchführen,
  • man Versionen vergleichen möchte oder
  • Daten aus anderen Systemen importiert werden könnten

zahlt es sich aus, nach Alternativen Ausschau zu halten.

Hier ein sehr schönes Beispiel von Sabine Hörmannsdorfer, die meinen Kurs an der FH Wien besucht hat. Einen sich schneller ändernden Datensatz, als das Beziehungschaos bei GZSZ kann man sich ohnehin nicht vorstellen. Ideal also, um Graphviz statt Powerpoint zur Hand zu nehmen.

Zunächst werden die Daten textuell definiert. Das hat den Vorteil, dass man dafür keine spezielle Software benötigt. So etwas kann man daher auch stressfrei kopieren, am Handy tippen oder Vorlagen aus dem Web klauen.

digraph G
{
	"Beziehungswirrwarr bei GZSZ" [shape=box, style=filled, color=darkorchid, fontcolor=white, fontname=verdana, fontsize=20.0]
	Philip;
	John;
	Ayla;
	Pia;
	Leon;
	Emily;
	Patrick;
	Jo;
	Dominik;
	Jasmin;
	Kurt;
	Katrin;
	Tayfun;
	Tuner;
	Zac;
	Vince;
	Tanja;
	Maren;
	Alexander;
	Lilly;
	"in einer Beziehung" [shape=box, style=filled, color=red]
	"verwandt" [shape=box, style=filled, color=forestgreen]
	"ex-Beziehung" [shape=box, style=filled, color=blue]
	"Sabine Hoermannsdorfer, PWOE 2013, Vertiefung IT-Systeme" [shape=none, fontcolor=gray20, fontsize=10.0];
	Ayla -> Philip [dir=both, color=red];
	Philip -> John [dir=both, color=forestgreen];
	Philip -> Emily [dir=both, color=forestgreen];
	John -> Pia [dir=both, color=red];
	Leon -> Pia [dir=both, color=red];
	John -> Emily [dir=both, color=forestgreen];
	Emily -> Patrick [dir=both, color=blue];
	Patrick -> Jasmin [dir=both, color=blue];
	Patrick -> Dominik [dir=both, color=forestgreen];
	Jasmin -> Dominik [dir=both, color=blue];
	Dominik -> Jo [dir=both, color=forestgreen];
	Jo -> Katrin [dir=both, color=blue];
	Jasmin -> Kurt [dir=both, color=red];
	Katrin -> Jasmin [dir=both, color=forestgreen];
	Katrin -> Kurt [dir=both, color=blue];
	Ayla -> Tayfun [dir=both, color=forestgreen];
	Zac -> Tanja [dir=both, color=blue];
	Vince -> Tanja [dir=both, color=blue];
	Lilly -> Tanja [dir=both, color=forestgreen];
	Maren -> Lilly [dir=both, color=forestgreen];
	Lilly -> Vince [dir=both, color=blue];
	Maren -> Tanja [dir=both, color=forestgreen];
	Maren -> Alexander [dir=both, color=red];
	Vince -> Leon [dir=both, color=forestgreen];
	Tuner -> Emily [dir=both, color=blue];
	Ayla -> Tayfun [dir=both, color=red];
	Kurt -> Tanja [dir=both, color=forestgreen];
	Alexander -> Katrin [dir=both, color=blue];
	Maren -> Kurt [dir=both, color=blue];
bgcolor=lightcoral //hintergrundfarbe ändern//
}

Läuft sogar unter Windows.

Die fertige *.dot-Datei wird anschließend mit dem Programm dot (.exe unter Windows) in ein Bild gerendert. Outputformat ist hier etwa PNG, es sind aber auch PDF und zahlreiche andere möglich.

dsfafg
Fertig ist der Output.

Der Output kann nach Belieben immer wieder aus der Textdatei erstellt werden. Änderungen sind so sehr schnell durchgeführt. Technisch und optisch ist so ziemlich alles möglich und sogar noch mehr.

IT explained

Excel ist die falsche Technologie!

Vergangenes Jahr war in einem meiner Blog-Posts zu lesen, dass Office-Dokumente mit grundlegenden Problemen behaftet seien. Jetzt will ich mich dem übelsten Vertreter der ohnehin schon wenig glorreichen Bande an Office-Dokumenten widmen: Der Tabellenkalkulation, in Controlling-Abteilungen dieser Welt auch ehrfurchtsvoll Excel Sheet genannt.

to excel heißt auf Deutsch hervorstechen. Die Arbeit mit Excel Sheets sticht im Regelfall durch folgende Eigenschaften hervor:

  • während der Entstehungsphase ist sie verführerisch einfach,
  • für andere ist sie aber bereits nach wenigen Klicks nicht mehr nachvollziehbar und daher
  • höchst fehleranfällig.
  • Ergebnisse sind am Ende selbst durch den Ersteller kaum noch reproduzierbar.

Die Tabellenkalkulation besetzt meiner Ansicht nach eine extrem kleine Nische zwischen Taschenrechner und Programmierung. In der Bürowelt ist vom Nischendasein allerdings keine Rede…

Ein Punkt am Rande: Wenn hier von Excel die Rede ist, sind natürlich auch sämtliche andere Formate wie etwa LibreOffice Calc oder Apples Numbers inkludiert. Da Microsoft allerdings einen derart hervorragenden Job beim Vendor Lock-in am Arbeitsplatzrechner macht, habe ich wenig Mitleid, wenn ein großer Teil der Kritik an Excel hängen bleibt.

Einfacher Start und Schrecken ohne Ende

Sehen wir uns die Entstehung einer Tabellenkalkulation anhand eines typischen Anwendungsfalls an: Budgetplanung.

Zunächst ist das Tool hilfreich: Ein paar Positionen untereinand platziert, das aktuelle Jahr mit Ist-Daten in der Spalte daneben, noch eine Spalte für die Plan-Daten im kommenden Jahr. Berechnung einer Preissteigerung, automatische Summenfunktion, fertig ist die Kalkulation!

A B C
1 2012 (Ist) 2013 (Plan)
2 Personal 120 =B2*1.04
3 Material 70 =B3*1.12
4 Sonstiges 5 4
5 Projekt 25 33
6 Summe =Summe(B2:B5) =Summe(C2:C5)

Excel stellt die Struktur wie im Bild unten hübsch dar. Doch hier beginnt bereits das Problem. Während der WYSIWIG-Ansatz bei Textverarbeitung (vielleicht) sinnvoll ist, führt er bei Kalkulationen zur Verschleierung der Kernaufgabe: “What you do is what I hide” ist das eigentliche Motto jeder Tabellenkalkulation.

What you see is what you get, WYSIWYG. Formeln werden automatisch ausgeführt, Ergebnisse hübsch dargestellt. Meiner Ansicht nicht Segen, sondern Fluch.

Komplexe Verschleierung

Excel versteckt demnach das, was es tut und präsentiert lediglich ein Endergebnis. Gerade wenn man über einen längeren Zeitraum oder gemeinsam mit anderen an so einem Tabellen-Moloch arbeitet, ist aber genau dieses Verhalten fatal: Die Sache wird bestenfalls unübersichtlich, in der Regel unüberschaubar.

Anders als bei Textdokumenten gibt es bei Tabellen nämlich keine “natürliche” Richtung in der sich der Inhalt ausbreitet. Zellenwerte, Formeln, Verweise, Fomatierungs-Einstellungen sowie Makros sind über das gesamte Dokument verstreut. Dabei ist das Dokumnt selbst ein Sammelsurium aus Tabellenblättern, eingebetteten Objekten oder Verlinkungen zu anderen Sheets auf SharePoint. Ich kann mich an Arbeitstage während des DWH-Projekts erinnern, da hätte man unsere Arbeit bestenfalls als Excel-Forensik bezeichnet.

Dazu kommt – der Goldstandard beim “Herumexceln” -, dass laut meinen empirischen Erhebungen rund 112% der Benutzer liebend gerne Informationen mit Hilfe der Formatierung codieren. Da werden also Farben, Schriftschnitte und insbesondere Hintergrundfarben zur Daten-Anreicherung verwendet. Beim Ausdrucken wird das Problem kritisch; die Lösung ist aber schnell gefunden: Man druckt künftig in Farbe.

Kurzum: Der hohe Grad an Flexibilität wird so zum Fluch – betriebliche Nebenwirkungen nicht ausgeschlossen:

“The most popular software for writing fiction isn’t Word. It’s Excel.” @brianalvey

Ein besserer Ansatz

Arrogant, wie ich eben bin, behaupte ich nun, eine bessere Lösung zu haben: Die strikte Trennung von Content und Design. Dieser Ansatz ist leider aber zu genial, als dass er von mir käme – es ist der rote Faden sämtlicher Softwareentwicklung und Datenhaltung seit ungefähr 1843.

Eine Tabellenkalkulation gehört demnach aufgeteilt in

  1. Daten,
  2. Berechnung,
  3. Design und
  4. Layout
Schematische Darstellung eines Kalkulationstools - theoretisch lässt sich aber auch Excel dahingehend verwenden.

Nun, meine Darstellung oberhalb umfasst mit Versionierung und Synopse zwar Konzepte, die in Excel nicht machbar sind, aber aus der Trennung von Daten, Berechnung, Design und Layout lassen sich einige hilfreiche Tipps – sogar für Excel – ableiten.

Sieben Excel-Tipps

… von jemand, der Excel hasst – von mir.

“It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.”

  1. Rohdaten und Formeln trennen.
  2. Richtung beibehalten: von oben nach unten, von links nach rechts arbeiten.
  3. Niemals Formatierung zur Codierung von Informationen verwenden.
  4. Sofern ein druckbares Ergebnis gewünscht ist, dies in einem eigenen Tabellenblatt “designen”. Dort aber nichts mehr berechnen, sondern nur noch mit Referenzen arbeiten.
  5. Weniger ist mehr und simple is better than complex.
  6. Sinnvolle, sortierbare Dateinamen ohne Sonderzeichen usw. vergeben. (Das Suffix “_neu” lässt sich durch “_neuneu” nicht besonders gut steigern.)
  7. Nach Alternativen (zB Python oder R) Ausschau halten.
IT explained

Vom Zynismus der IT-Leute

Jahresbeginn ist die Zeit der guten Vorsätze. Ich habe mir vorgenommen, etwas für die Verständigung zwischen “normalen” Menschen und Nerds zu tun, bzw. selbst ein wenig verständnisvoller zu sein. Aber alles der Reihe nach:

Ich höre immer wieder Beschwerden, ITler seien wahre Unmenschen, die den Büroalltag vieler Unternehmen mit Sarkasmus und Ironie überschwemmen. Von der gegnerischen Seite – gleichsam egal aus welcher Branche oder Position – höre ich, die jeweiligen DAUs seien besonders schlimm und grundsätzlich verständnislos gegenüber der IT.

Wie ich es erlebe, führt die geschilderte Situation zu Subkulturen innerhalb der Unternehmen. IT Profis fühlen sich dann dort grundsätzlich mehr ihren Projekten oder technischen Religionsbekenntnissen als ihren Arbeitgebern zugehörig. Ergebnis sind einerseits zwar Meilensteine des Humors, andererseits aber auch viel Konflikt- und Frustrationspotential.

Zynismus, wörtlich Hündigkeit, bezeichnet eine Lebensanschauung, die durch Spott und Missachtung von Konventionen geprägt ist. Dabei ist oft der einzige Hund, mit dem ITler zu tun haben, der Höllenhund Kerberos, ein Protokoll zur Authentifizierung über Netzwerke. Der Großteil von uns ist nämlich nett und beißt nicht;-) Foto: Mathias, Mosambik 2011.

Nun, viele Vorurteile mögen stimmen, das Pauschalurteil Unmensch will ich aber zurückweisen. Die IT-Leute, die ich kenne, zeigen soziales Engagement durch Freiwilligenarbeit oder überdurchschnittliches Spendeverhalten. Der Referenz-Nerd ist Pazifist, an tausenden Dingen außerhalb der IT interessiert, reist viel und ist grundsätzlich eher freundlich. Die komplette Industrie fußt dank Open Source auf dem Grundsatz gemeinschaftlichen, unentgeltlichen Teilens – in allen anderen Wirtschaftsbereichen wäre das eine reine Utopie.

Kurzum: Es gibt definitiv das oben geschilderte Problem, aber es ist kein charakterliches.

Ein Problem zweier Welten

Vielmehr bin ich der Überzeugung, dass es ein Problem zweier, stark unterschiedlicher Realitäten ist. Dies erzeugt ein Spannungsfeld, mit dem ITler tagtäglich konfrontiert sind. Auf Dauer ist so etwas aufreibend – die (verzweifelte) Reaktion ist dann oft sarkastisch.

Auf der einen Seite befindet sich die Welt des Unternehmens und des Managements; es ist die Bürowelt hierarchischer Ordnung mit (anscheinender) Beliebigkeit der Verwaltungsentscheidungen.

Im krassen Gegensatz dazu steht die technik-getriebene Welt der IT; hier sind gute Mitarbeiter unerreichte (aber auch unüberprüfbare) Experten auf ihren Gebieten – Entscheidungen basieren deutlich öfter auf Fakten oder, zumindest, technischer Notwendigkeit.

 +++ Spannungsfeld zwischen non-IT und IT +++
                  Bürowelt                IT
--------------------------------------------------------------------------
Entscheidungen    Fingerspitzengefühl     README.txt
der Weg dahin     Meetings                Konkurrenz und Evolution
Motivation        mission statements      das beste System bauen
Organisation      hierarchisch            (latent) in Task Forces
Qualität          langfristig nebulös     automatisiert überprüfbar
Fehler            Ausnahmen einführen     Totalabsturz
Fehlerbehebung    schwer                  STRG-Z
ArbeitsINPUT      skaliert mit Zeit       skaliert mit Konzentration
ArbeitsOUTPUT     linear zur Fallzahl     Zahl unterschiedlicher Fallarten
Projektmanagment  schwerfällig, genau     agil, trial & error
Planbarkeit       Excel                   Glaskugel
Umsetzung         Papier                  Code
Wartungsaufwand   Wartung?                hoch

Vielleicht hilft ein Beispiel zur Verdeutlichung meiner Gedanken.

Als ich 2002 “richtig” zu arbeiten begonnen habe, wurde mein Mitarbeiter-Account in die Unix-Gruppe “edvz” gesteckt. Das EDV-Zentrum war zwar zu dieser Zeit bereits Geschichte, das zugrunde liegende IT-System ließ sich aber nicht mehr so leicht umbiegen. (Wozu auch?) Inzwischen gab es eine neuerliche Umbenennung von ZID in IT-S. Accounts sowie aber vor allem auch deutlich wichtigere Systeme machen solche Aktionen aber selten mit. Es entsteht ein Spannungsfeld zwischen “Realität” und dem, wie sie in Systemen abgebildet wird.

Als IT-Mitarbeiter ist man also täglich mit diesen zwei Welten konfrontiert. Einerseits hört man, wie etwas laut Management, Verkauf oder Gesetzgeber zu sein hat oder angeblich ohnehin bereits so ist, andererseits liegt vor einem das tatsächliche Regelwerk gegossen in Programmcode. Und dieser kennt keine Ausnahmen und duldet keinerlei Fehler oder Mehrdeutigkeiten. Das Problem zieht such durch alle betrieblichen Sphären (und erreicht bei HR seinen traurigen Höhepunkt).

Ich bin überzeugt, dass bei meiner Hausbank (zurzeit heißt sie übrigens gerade Bank Austria Unicredit AG) auch heute noch im Hintergrund die Abrechnungsprogramme, Clearing-Skripts und automatisierten Risikoanalysen der Zentralsparkasse mit denen der Creditanstalt konkurrieren. Die Hausbank, die sich – seit sie mich als Kunden hat – drei Mal umstrukturiert hat, besitzt mit Sicherheit auch zynische IT-Mitarbeiter. IT-Mitarbeiter, die ganz genau wissen, dass der Logotausch auf der Homepage noch keine andere Bank aus ihrem Unternehmen macht.

Klar, man könnte nun mit Kernprozessen und der reinen Hilfsfunktion von IT kontern. Aber wenn ich mir am Beispiel der Banken ansehe, woher die Konkurrenz kommt (Direktbanken, Mobilfunker und NFC, peer to peer finance), würde ich sehr schnell Information als Kernressource meines Unternehmens ansehen. Und damit wäre die IT wissensintensiver Unternehmen auf Augenhöhe mit dem Controlling – zugegeben, das ist nun wirklich eine Utopie…

Versöhnliches

Kommen wir zum versöhnlichen Abschluss, immerhin ist’s ja mein Neujahrs-Blog.

Ich stelle fest, Nicht-ITler haben oft keine Vorstellung davon, welche Tätigkeiten viel und welche wenig Aufwand auf meiner Seite bedeuten. Mit größter Selbstverständlichkeit wird da oft ein komplettes Datenbank-Redesign eine Woche vor dem Produktivtermin gefordert, beinahe ängstlich wird manchmal gefragt, ob man die Schriftfarbe jetzt überhaupt noch anpassen könnte.

In Zukunft werde ich die Komplexitäten meiner Arbeit besser darlegen. Vielleicht wird dann klar, dass auch ich kein so unguter Hund bin.

IT explained

Alternative zu Office-Dokumenten

Kürzlich habe ich über mein grundsätzliches Problem mit Office gebloggt. Dabei ging es mir nicht um ein Microsoft-Bashing, weil mir MS Office nicht gefällt. Nein, mir gefällt das Konzept von Office Dokumenten grundsätzlich nicht. Eine Suche nach “Office Alternative” liefert mit Open Office & Co. lediglich die Konkurrenten der Suite aus Redmont, nicht aber das was ich im Auge habe. Ergo:

“Wenn mir ein Badeurlaub in Griechenland nicht gefällt, fahre ich ja auch nicht im kommenden Jahr an die türkische Riviera. Ich mache eine andere Art von Urlaub.”

Paradigmenwechsel an der Tastatur

Diese grundsätzlich andere Art von Dokumentenerstellung hat viel mit den Konzepten zu tun, die für Softwareentwickler das tägliche Brot bedeuten: Abstraktion von Problemstellungen sowie Trennung von Design und Content. Zuviel der vielen Worte, hier also ein Beispiel.

Beginnen wir mit dem, was jeder kennt: Powerpoint. Die fiktive Aufgabenstellung ist das Visualisieren eines einfachen Prozesses anhand eines Flußdiagramms. Keine fünf Minuten später ist das Ergebnis fertig.

Ein Flussdiagramm ist schnell zusammengeklickt

Die gänzlich andere Herangehensweise ist die Abkehr von WYSIWYG. Anstatt im fertigen Dokument herumzuklicken, strukturiert man die Daten in einer einfachen Textdatei.

digraph {
  "Urlaubsantrag anlegen" -> "Genehmigung";
  "Urlaub auswählen" -> "Genehmigung";
  "Genehmigung" -> "Urlaub fix buchen";
  "Genehmigung" -> "Vertretung zum Blumengießen suchen";
}

Ein Programmpaket namens Graphviz übernimmt anschließend das Layoutieren. Ich habe mich also auf die Daten konzentriert, die Anordnung der Knoten und Kanten übernimmt die Software.

Die Alternative mit Graphviz. Vielleicht zu Beginn nicht ganz so schön, aber die Vorteile kommen noch...

Wer nun ästhetische Bedenken hat, soll sich die Graphviz Gallery ansehen, die gleichzeitig auch der beste Startpunkt zum selbst Experimentieren ist. Spielstand im Match Powerpoint gegen Graphviz bisher also eins zu eins.

Und hier beginnen die Vorteile

Die entscheidenden Vorteile beginnen bei nun folgenden Änderungswünschen. Angenommen wir müssen einen weiteren Prozessschritt zwischen “Urlaubsantrag anlegen” und “Genehmigung” schieben. In der Office-Lösung bedeutet das, dass der Benutzer mit dem Verschieben der Kästchen beginnt, mühsam die Pfeile nachzieht, früher oder später ernsthafte Probleme mit der Positionierung bekommt, da Graphen ja meist dort wachsen, wo ohnehin kein Platz mehr zu sein scheint. (…)

In der alternativen Lösung ist lediglich eine Zeile Text zu ändern.

digraph {
  "Urlaubsantrag anlegen" -> "Beten" -> "Genehmigung";
  ...
}

Bei umfangreicheren Dokumenten führt der Office-Approach zu zahlreichen Problemen wie etwa höherem Arbeitsaufwand mit repetitiven Herumgeklicke. Auch das Vergleichen von Versionen ist mit der Graphviz-Lösung kein Problem. So gibt es es zahlreiche Tools, die eine Synopse (ein sogenanntes Diff) von Textdateien visualisieren. Bei Powerpoint heißt es dann eher “Nimm’ die Version, wo das Hackerl dort noch angeklickt  und die Farbe auf das zweite Hellgrau von unten gesetzt war”. In der Welt von Word führt das Vergleichen von Dokumentenversionen zu so unglaublich komplexen, verwirrenden und letztlich unbrauchbaren Features wie der Änderungsnachverfolgung – ich kapier’ diese zumindest bis heute nicht.

Der Weg in eine bessere Bürowelt ist frei!

Kurzum: In vielen Situationen liegt die Komplexität nicht beim einmaligen Erstellen eines Dokuments, sondern in der Frage, wie man mit Änderungen (oft durch mehrere Benutzer) langfristig umgeht. Wann immer das der Fall ist (und das ist es fast immer!), empfiehlt sich ein Lösungsweg abseits von Office-Dokumenten. Hier also ein paar Startpunkte:

  1. Für Graphen (wie etwa das Flussdiagramm oben) verwende ich Graphviz.
  2. Für Textdokumente aller Art verwende ich LaTeX.
  3. Protokolle, Projektpläne und ähnliche Daten liegen ohnehin besser in Form von Wikis vor.
  4. E-Mails sollten in Klartext gesendet werden. Damit bleiben die Inhalte durchsuchbar und auf allen (mobilen) Devices lesbar.
  5. Tabellenkalkulationen braucht man grundsätzlich nicht! Entweder man verwendet ordentliche Datenbanken, Programmierumgebungen oder einen Taschenrechner. (Über den Spreadsheet-Virus, der die Betriebswirtwelt befallen hat, werde ich vielleicht nochmal bloggen.)
  6. Für Berechnungen oder Diagramme empfehlen sich Programmiertools wie R, Processing oder Python.
  7. Bleiben Präsentationen und Bildverarbeitung: Hier ist der WYSIWYG-Ansatz wahrscheinlich der Richtige. Also keine Belehrung von meiner Seite;-)
meta

Was machen eigentlich Programmierer?

Vergangene Woche wurde ich wieder gefragt: “Mathias, was tust du eigentlich so als Programmierer?”

Ich finde es erstaunlich, dass in einer inzwischen durch und durch digitalisierten Welt nach wie vor wenig Außenstehende Ahnung davon haben, woraus die Arbeit eines Softwareentwicklers besteht. Dabei durchdringt die Softwarewelt die reale: Nachrichtenmeldungen sind voll mit Berichten über Software-Features wie Gesichtserkennung, Einkaufen via QR-Codes, Suchalgorithmen, Videotelefonie usw. Gleichzeitig ist die Anatomie dieser Systeme den meisten Menschen gänzlich unbekannt. Es herrscht flächendeckender IT-Analphabetismus.

Programmieren hat wirklich nichts mit Office-Software zu tun

Ein Grund der oben geschilderten Situation ist sicherlich, dass IT-Fähigkeiten meist auf Office-Kenntnisse beschränkt werden, und diese Fehleinschätzung zusätzlich mit fragwürdigen Zertifizierungen wie dem Europäischen Computer Führerschein (ECDL) institutionalisiert wird. Ich kann jedenfalls behaupten, dass ich tagelang produktiv arbeiten kann, ohne ein Office-Dokument geöffnet zu haben.

Ein Grund, warum Softwareentwickler Office-Dokumente dermaßen verabscheuen, ist womöglich folgender: In Word- oder Excel-Dateien liegen Informationen unstrukturiert vor, die Daten sind somit für eine effiziente Weiterverarbeitung verloren. Während sich Anwender meist zeitraubend um das Einfärben und Positionieren von Überschriftszeilen bemühen, geht es Entwicklern eher darum, wo Informationen gespeichert und wie sie (weiter-) verarbeitet werden.

“Kurzum, es ist eine sehr spannende Aufgabe ein Programm zu schreiben, dass hunderte Spreadsheets erzeugt und per Mail versendet. Es ist fürchterlich, auch nur eine einzige Excel-Datei selbst zu erstellen!”

Also was machen nun Programmierer genau?

Dank dem rasanten technischen Wandel besteht ein großer Teil meiner Arbeitszeit aus Weiterbildung.

Eins vorweg: ich bevorzuge den Begriff Softwareentwickler, da ich deutlich weniger Zeit an der Tatstatur verbringe, als vermutlich angenommen wird. Meine Arbeit besteht zu großen Teilen aus Recherche und somit Lesen, Versuchen  nach dem Trial-and-Error-Prinzip anstatt zu detaillierter Planung, Kaffeetrinken, Anwender interviewen, Bugs rekonstruieren und fixen, Dokumentationen in Form von Wikis oder automatisierten Softwaretests schreiben und Besprechungen führen. Ich verbringe maximal 20% meiner Arbeitszeit mit tatsächlichem Programmieren am endgültigen Produkt. Bei wirklich produktiven Leuten ist der Anteil wahrscheinlich maximal doppelt so hoch.

Datenbanken, Programmiersprachen und Betriebssysteme

Wie oben erwähnt strukturieren Softwareentwickler die Welt der Daten und machen diese so zu wertvoll(er)en Informationen. Wer also auf seinem Desktop Dateien mit etwa folgenden Namen speichert, sollte sich schleunigst Gedanken über Datenbanken machen:

Urlaubsliste.xlsx
Urlaubsliste_neu.xlsx
Kopie von Urlaubsliste_neu.xlsx
Urlaubsliste_neu - 21. März 2011.xlsx
Urlaubsliste (Version Kontrolle MF).xlsx
Urlaubsliste - endgültig nicht bearbeiten!.xlsx

Ein zentraler Bestandteil eines Entwicklerdaseins sind die verwendeten Programmiersprachen. Je nach Anwendungsgebiet oder Erfahrung gibt es zahlreiche Optionen. In Entwicklerkreisen gleicht die Wahl der Programmiersprache dem Religionsbekenntnis. Ähnliches Bild auch auf Seiten der Betriebssysteme, nur ist hier die Auswahl deutlich geringer: Es gibt die Windows-Leute auf der einen Seite und Unix-Anwender auf der anderen. (Apples MacOS ist übrigens lediglich ein sehr hübsches Unix.)

Fazit: Sollte sich jemand fürs Programmieren interessieren, dann wird man ohnehin mit all den Begriffen schnell in Kontakt geraten. Vielmehr als konkrete Sprachen oder Systeme zählen ohnehin die Aufgabenstellungen. Motto: Such’ dir ein interessantes Problem und kämpf’ dich durch zur Lösung.

Versionskontrolle und Wissensmanagement

Softwareentwicklung ist stetige Wissensfindung als Produktionsprozess. Dabei ist der entstandene Source-Code die Dokumentation der erfolgten Arbeit. Umfangreiche Projekte bestehen aus hunderten von Dateien. Bugs lauern überall, Änderungen im File A haben meist unabsehbare Auswirkungen auf das Gesamtsystem. Bei Projekten mit mehreren Entwicklern steigt der Kommunikationsaufwand exponentiell, sehr schnell ist der Überblick verloren.

Die Lösung des Problems sind unter anderem Systeme zur Versionskontrolle, die das Projekt nicht auf Ebene von Dateien, sondern so genannten Revisionen organisieren. Mich wundert bis heute, warum diese Funktionalitäten nach wie vor nicht Einzug in die Bürowelt gefunden haben. Wenn überhaupt, dann sind sie allerdings extrem komplex aber gleichzeitig nutzlos umgesetzt.

Traumberuf Softwareentwickler

Das Schöne an der Softwareentwicklung ist letztlich, dass die vielfältigen Tätigkeiten nicht in eine kurze Erklärung passen. Jede Aufgabenstellung ist in gewisser Weise einzigartig.

Jeden Tag eine neues Projekt: die Nicht-Standardisierbarkeit der Aufgaben ist der einzige Standard.

Ich habe in zehn Jahren IT noch keinen Softwareentwickler getroffen, der nicht Spaß an seiner Arbeit gehabt hätte. Dennoch birgt die Arbeit großes Frustrationspotential.

Einerseits kann man schon mal tagelang auf drei Zeilen Code starren und absolut nicht verstehen, warum das Programm nicht so funktioniert, wie die Dokumentation sagt. Andererseits werden oft die größten Fortschritte nicht als solche anerkannt. Es gibt schlicht keinen Zusammenhang zwischen Programmieraufwand oder technischer Komplexität und Applaus der Benutzer. Situationen in denen die Benutzer schlicht nicht wissen (können) was eigentlich dahinter steckt, so genannte Black Triangles, sind sehr weit verbreitet.

Zum Abschluss: Softwareentwicklung ist für mich der spannendste Bürojob auf Erden. Ich schaffe tagtäglich meine eigene Welt aus Programmcode, der für mich wie Poesie wirkt. Woche für Woche lerne ich etwas Neues von Menschen, die ihre Arbeit im Internet frei zur Verfügung stellen.

Die einzige Limitation in der Welt der Bits und Bytes ist letzlich die Vorstellungskraft der Entwickler. Hoffentlich kann sich bald jemand eine vernünftige Alternative zu Office-Dokumenten vorstellen…