Tag Archives: software

IT project management

Checklist Softwareauswahl

April 22, 2012 – 2012-04-22 5:59:10

Knappe eineinhalb Jahre vor Inbetriebnahme des Campus WU werden aktuell zahlreiche Softwareprodukte unterschiedlicher Größe beschafft. Software ist durch ihre nicht überschaubaren Anwendungsmöglichkeiten komplex, die Auswahl des richtigen Produkts daher keine triviale Aufgabe.

Im Zuge der Beschaffung eines Geoinformationssystems (GIS) fand allerdings ein Bilderbuchbeispiel für einen strukturierten Entscheidungsprozess seinen Weg bis zur Vertragsunterzeichnung; ein Beispiel, das ich in abstrakter Form hier gerne teile.

Ausgangspunkt

Wir kaufen also Unternehmens-Software: Diese ist im Jahr 2012 beinahe immer webbasiert, oder zumindest in einer three tier architecture umgesetzt. Das Unternehmen möchte die Gesamtkosten (total cost of ownership) minimieren, dabei aber dennoch eine ausreichend gute Software einführen.

Im Studium lernte ich die Nutzwertanalyse als Werkzeug bei derartigen Entscheidungsprozessen kennen. Als ich sie vor Jahren zum ersten Mal anwenden wollte, erlebte ich allerdings zahlreiche Probleme: Die Punktevergabe samt Gewichtung gaukelt ein genaueres, transparenteres Ergebnis vor, als es tatsächlich ist. Gewichtungen werden oft auch noch nachträglich verändert. Die Betriebswirtschaftslehre nennt das Sensitivitätsanalyse, in der Praxis ist das eher ein Hintricksen zum gewünschten Ergebnis.

Was ich an Methoden agilen Projektmanagements mag, ist weniger die Fähigkeit, Prozesse vielleicht besser steuern zu können, sondern die im Lieferumfang enthaltene Transparenz mit der Unsicherheit und Ungenauigkeit nach außen hin als solche deklariert werden.

Soll heißen: Ich präsentiere hier eine absichtlich zur Checklist verkommene Nutzwertanalyse, weil jedes mehr an Datenpunkten, lediglich mehr Zahlenspiel als sinnvolle Entscheidungsgrundlage bedeutet. Anstatt Punkten und Gewichtungen treten nur noch drei Zustände: KO, entscheidend, relevant. Während KO als Filter zu sehen ist, sind die beiden letzteren rein qualitative Aussagen: “Dieses Kriterium ist entscheidend und Anbieter A ist da wohl ein wenig besser” – mehr ist nicht möglich.

Nutzwertanalyse “light”

Zuerst zur Software selbst
  1. Erfüllt die Software alle meine mir jetzt bekannten Anforderungen? Gibt es zumutbare Workarounds für fehlende Anforderungen?
    (KO-Kriterium)
  2. Kann die Software deutlich mehr, als ich es will? Paradox: Je mehr unnötige Funktionalität geboten wird, desto schlechter!
    (siehe: Complexity kills!, entscheidend)
  3. Können alle künftigen Endanwender den Client verwenden oder gibt es Einschränkungen bei Browserversionen und/oder Betriebssystemen? Gilt dies auch noch künftig in meinem Unternehmen?
    (KO-Kriterium)
  4. Falls ein mobiles Szenario existiert: Ist der Service mobil nutzbar?
    (relevant)
  5. Ist eine zentrale Authentisierung (Login mit unternehmensweitem Passwort) möglich?
    (KO-Kriterium)
  6. Ist eine zentrale Autorisierung (Übernahme zentral gepflegter Berechtigungen) möglich?
    (relevant)
  7. Falls ein älteres System abgelöst wird: Können Daten übernommen werden?
    (entscheidend)
  8. Wie schätze ich die wirtschaftliche Situation des Anbieters ein? Wird es ihn in fünf Jahren noch geben? Ist sein angebotenes Produkt für ihn selbst wichtig oder wird mir ein Auslaufmodell angeboten? (Product Roadmap) Wie stark ist letztlich meine Abhängigkeit?
    (entscheidend)
    ODER
    Handelt es sich um Open-Source Software? Gibt es andere Anbieter, die auf Basis dieser Software Dienstleistungen anbieten?
    (relevant. Das bedeutet, dass dieser Punkt im Falle von OSS weniger Tragweite erhält.)
  9. Liegen die Daten in einem lesbaren Format vor, oder sind sie im System des Anbieters gefangen?
    (entscheidend)
  10. Kann ich das System (notfalls) selbst administrieren? Gibt es ausreichend Angebote für Dienstleistungen (Beratung, Support, Administration), wenn möglich auch von anderen Anbietern?
    (entscheidend)
  11. Gibt es Referenzen? Habe ich Erfahrung von anderen Installationen des Anbieters in meiner Branche? Welches Feedback ergibt eine Netz-Recherche?
    (relevant)
  12. Was sagen meine Endanwender? Hat Ihnen die Produktpräsentation gefallen? Gefällt ihnen die Software?
    (arrogant, aber: beinahe irrelevant)
  13. Bietet das System offene Schnittstellen für Daten und/oder Automatisierung?
    (entscheidend)
  14. Erfüllt das System meine Sicherheitsanforderungen hinsichtlich Architektur, Datenhaltung, Verschlüsselung, usw.? Ist das Angebot “in der Cloud” bzw. gebe ich unternehmenskritische oder datenschutzrechtlich sensible Daten in fremde Hände?
    (KO-Kriterium)
  15. Darf ich das System in dieser Form einsetzen, oder spricht geltendes Datenschutz-Recht dagegen? Besitze ich eine Meldung beim DVR oder ist gar mit einer Ablehnung zu rechnen?
    (realistischerweise lediglich relevant)
  16. Passt die vom Anbieter vorgeschlagene Vorgehensweise bei der Einführung zu Kultur und Ressourcen meines Unternehmens? Sind etwa Schulungen zeitlich möglich? Wissen alle Stakeholder überhaupt von ihren künftigen Rollen?
    (relevant)

Man sieht, in meiner Auflistung fehlen zentrale Punkte, die normalerweise (stärker) repräsentiert sind. Dazu zählen etwa die Zufriedenheit der Nutzer oder die technische Ausgereiftheit des Produkts.

Bei einer Produktpräsentation etwa bewerten Endanwender eher die sympathische Art des Beraters, nicht aber das Produkt selbst. Bewerten sie in Ausnahmesituationen doch die Software anstatt der Powerpoint-Präsentation, lassen sie sich vom GUI blenden und schaffen es de facto nie, das Gezeigte zu abstrahieren und in ihre Arbeitswelt zu überführen.

Doch auch IT-Spezialisten sind schlecht im Bewerten: In zehn Jahren IT habe ich festgestellt, dass in Systeme nicht hineingesehen werden kann. Die traurige Nachricht lautet, dass man alle Probleme am eigenen Leib erleben wird, bevor man sie mühsam lösen muss. Dabei gibt es kaum Unterschiede zwischen Open Source und kommerzieller Software: Bei ersterer ist tendenziell mehr Expertenwissen bei der Problemlösung vonnöten – bei höheren Erfolgsaussichten -, bei zweiterer sind zeitlicher Aufwand (Support-Hotline!) und monetärer Einsatz (Beratertage) weitaus größer.

Den Reifegrad einer Software anhand des Namedroppings von Programmiersprachen, Protokollen, Datenbanksystemen, Dateiformaten, usw. feststellen zu wollen, ist blanker Unsinn. Verwendete Technologie und Qualität korrelieren äußerst schwach. Die Eckpunkte von Softwarequalität lauten Entwicklungsprozess, automatisiertes Testen, Sourcecodemanagement, Erfahrung & Motivation, … – alles Dinge, die von außen gänzlich unsichtbar sind.

… und dann das Geld

Nun zu den Kosten: Diese sind bei Hardware und Lizenzen zwar noch vergleichbar, aber oft stellen Schulungen, Beratungsleistungen, Support u.ä. ein großes Problem dar. Veranschlagt ein Anbieter etwa das Doppelte für Beratungsleistung, kann es gleich mehrere Gründe dafür geben: Das System ist schwieriger einzuführen, die Berater sind teurer, der Anbieter ist vorsichtiger bezüglich des Projektfortschritts, usw.

Ein möglicher Ausweg ist die Aufschlüsselung der Kosten in angebotene Gesamtstunden und Stundensatz. Der Median der angebotenen Stunden (über alle Angebote hinweg) ist zunächst die beste Näherung für den Aufwand. Mit dem jeweiligem Stundensatz multipliziert kommt man so zu normierten Angeboten hinsichtlich der Dienstleistungen.

Diese so errechneten (fiktiven!) Angebote sollten Basis eines Preisvergleichs sein.

Eine Pattstellung zwischen zwei Anbietern ist aufgrund der bestehenden Unsicherheit nach wie vor äußerst wahrscheinlich. Möglicher Ausweg hier: Beauftragung beider Anbieter mit einer in maximal acht Wochen durchführbaren Pilotphase bei voller Transparenz des Modus und fairen Bedingungen.

Diese Vorgehensweise stellt die beiden Anbieter in direkten Wettbewerb. Man kann davon ausgehen, dass die “Motivation” auf beiden Seiten hoch sein wird. Auch im nachfolgenden (Groß-)Projekt – wenn dann die Auswahl letztlich getroffen ist – kann das Ergebnis der Pilotphase als Qualitätsreferenz dienen. (Der Anbieter legt sich selbst eine hohe Latte.)

Während die Methode bei kleineren Beauftragungen übertrieben scheint, stellt sie bei wichtigen Projekten eine probate Möglichkeit dar, Entscheidungsunsicherheit tatsächlich zu reduzieren.

Tags , , , , | Permalink | Comment (0)
hacks

CO2-Messung für Personenzählung

September 29, 2011 – 2011-09-29 5:06:25

Die Idee ist ebenso genial wie einfach zugleich: Personen produzieren CO2. Der Gehalt des Gases in der Raumluft lässt daher Rückschlüsse auf die Anzahl der Atmenden zu. Soweit die Hypothese – Zeit für einen Reality Check.

Am Campus WU ist die Klimatisierung in eine umfassende Gebäudeleittechnik integriert. Wo früher mühsam verkabelt wurde, da reicht heute ein einziges TCP/IP-Signal aus. Zu Testzwecken haben wir einen CO2-Sensor mit Webserver ausgestattet und in einem Hörsaal (2.18) der WU platziert.

Im Hörsaal befindet sich ein CO2-Sensor, der Rückschlüsse auf die Raumbelegung liefern soll.

Von der Decke des Hörsaals aus wird nun ununterbrochen gerochen, in einer Datenbank wird der CO2-Wert protokolliert.

It works!

Die Freude war jedenfalls groß, als heute das Setup in Betrieb genommen wurde und auch sofort “angeschlagen” hat.

Unter dem CO2-Sensor stehen und sprechen, kurz rausgehen, direktes Hineinatmen, Raum verlassen. It works!

Was nun?

Nun folgt eine mathematische Aufgabe: Wie kommen wir von einem Co2-Level (eigentlich einer elektrischen Spannung) zu einer Personenzahl? Der Wert wird stark von der tatsächlichen Kubatur des Raums abhängen, von Faktoren wie Zustand der Fenster und der Klimatisierung; bösartig könnte man auch noch den Inhalt der Lehrveranstaltung als Faktor ansehen. Meine Meinung: Menschen können Muster ohnehin sehr gut erkennen; der Mockup des künftigen Raumbuchungs-Systems zeigt bereits ohne errechnete Werte, was Sache ist:

Kleine Diagramme visualisieren den Verlauf des CO2-Gehalts; Menschen sind ohnehin gute Muster-Erkenner bei geeigneter Darstellung.

Update

Mit 3. Oktober konnte ich das Setup erstmals mit echten Lehrveranstaltungen testen. Laut Vorlesungsverzeichnis gab es zwei Lehrveranstaltungen, die gebuchten Zeiten habe ich farblich hinterlegt. LV1 hat 15 Minuten verspätet begonnen, es gab zusätzlich ein paar Pausen oder geöffnete Fenster. LV2 lief lediglich rund 20 Minuten – durchaus üblich zu Semesterbeginn, wo beispielsweise nur der Ablauf erklärt wird.

CO2-Verlauf im Raum während des Tages und zwei gebuchten Lehrveranstaltungen.

Tags , , , , , , | Permalink | Comment (0)
ideas

Von Software-Qualität und Eisbergen

September 16, 2011 – 2011-09-16 9:43:49

In Kürze gehen zwei unserer Anwendungen in Testbetrieb (gebloggt und nochmal gebloggt). Nach wochenlanger Entwicklungsarbeit naht nun der Moment, den ich so hasse: der Moment des ersten, überhasteten Feedbacks.

Ich will diesen Moment als Eisberg-Moment bezeichnen. Er findet da statt, wo Endbenutzer oder Auftraggeber erste Rückmeldungen zum Softwareprodukt liefern. Rückmeldungen, die lediglich die sichtbaren Merkmale der Software betreffen und somit den Großteil der Anstrengungen außer Acht lassen.

Auch wenn Usability-Leute behaupten, the interface is the product, dann ist das nur die halbe Wahrheit. Insbesondere über einen Bewertungszeitraum, der länger als fünf Minuten – in unserem konkreten Fall hoffentlich mehr als fünf Jahre – dauert, spielen ganz andere Faktoren die Hauptrolle:

  • Investitions- und Wartungskosten; die IT ist schließlich ohnehin personalintensiv.
  • Wartbarkeit
  • Security
  • Verfügbarkeit
  • Konsistenz/Integrität
  • usw. (…) Nur eben nicht Logos, Schriftarten und oder Ränder drumherum.

Kurzum, mein Kollege Dennis und ich haben den Eisberg auf einem Whiteboard verewigt. Unter der Oberfläche liegen die unbeachteten Merkmale von Software-Qualität. Auf der x-Achse haben wir die investierte Arbeitszeit aufgetragen; auf der y-Achse (zugegeben etwas sarkastisch) das Geld, das man mit den jeweiligen Services verdienen kann.

Qualitätsmerkmale von Software(-projekten) und was davon für Außenstehende sichtbar ist. Der "Eisberg-Moment", ein künftiger Management-Klassiker.

Der Eisberg-Moment ist übrigens das Gegenteil des black triangle moments.

Edit 1: Ich bin übrigens der Meinung, dass Feedback wichtig ist. Es sind nur diese ersten Rückmeldungen, die mich immer und immer wieder an den Rand der Verzweiflung treiben…

Edit 2: Passend zum Thema, dass Feedback qualitativ sehr unterschiedlich sein kann: TornadoGuard bei xkcd.

Tags , , , , , | Permalink | Comment (0)
IT explained meta

Von Dateien und der Zukunft des Internets

August 11, 2011 – 2011-08-11 3:03:37

“Das ist ja nur ein Link ins Wiki. Kannst du mir das nicht als ordentliche Datei geben?” Auf diese Aufforderung hinauf konnte ich unlängst nur irgendwas von HTML und “eh Datei” stottern. Aber:

Was ist eigentlich eine Datei?

Zunächst, Dateien existieren nicht wirklich. Sie sind nicht real, wie dies zum Beispiel Briefe, Urkunden oder die Post-its auf meinem Monitor sind. Daten auf einer Festplatte sind nichts Weiteres als eine lange Serie von Einsen und Nullen. Erst Betriebs- und Dateisystem präsentieren uns diesen Datenstrom als Dateien.

Dabei ist es oft der Fall, dass eine “Datei” in Wirklichkeit viele sind (Office), viele “Dateien” eigentlich nur eine (Mail, Datenbanken), oder das manche Systemkomponenten ansich Dateien sind, aber für uns gar nicht danach aussehen (Grafikkarten, Internetverbindungen, etc.).

Das weit verbreitete mbox-Format ist ein gutes Beispiel dafür, dass Anwendersicht und System ziemlich unterschiedlich sein können. Eine ganze Mailbox entspricht hier nur einer Datei. Der Mail-Client gibt sich anschließend alle Mühe, Mails so zu präsentieren, als wären sie  einzelne Dateien. Filme kommen heutzutage nur noch in sog. Container-Formaten über die Leitung und selbst die neuen Office-Dateien (xlsx, docx, etc.) sind vielmehr gezippte Archive als “klassische” Dateien.

Wer glaubt also nun ernsthaft, bei Twitter kämen jede Minute an die hunderttausend *.tweet-Dateien herein, und Mark Zuckerberg müsste die *.like-Files regelmäßig auf Viren untersuchen? Kurzum: Herkömmliche Dateien sind mehr Schein als Sein.

Ich behaupte, Dateien haben vielmehr mit der Haptik zu tun, als mit der tatsächlichen Repräsentation auf einem Speichermedium. Und die Erkenntnis hat viel mit der Zukunft unseres Nutzungsverhaltens mit Computern und dem Netz zu tun – glaube ich.

Keine Ahnung wer sich die Metapher mit den Dateien ursprünglich einfallen ließ, aber sie ist eine unglaublich starke: Akte, Aktenordner und Schreibtischplatte sind die deutschen Übersetzungen der deutlich besser klingenden Originale File, Directory und Desktop. Der Erfolg der Datei liegt darin, dass man etwas in der Hand hat, dass es so eine gut vorstellbare Entsprechung in der realen Welt gibt. Ablegen, Aufmachen, Kopieren, Löschen; über so eine Datei hat man Kontrolle genauso wie über einen Papierhaufen am echten Schreibtisch. Programme waren im Umgang bislang deutlich komplexer, aber dann kamen bekanntlich die Apps:

Vom Erfolg der Apps

Apps sind in aller Munde. Eine Webseite reicht nicht mehr aus, heute muss man im App Store oder Android Market sein. Während dieser Trend gegen alles verstößt, warum das World Wide Web ursprünglich erfunden wurde – nämlich um Informationen plattformunabhängig teilen zu können -, befriedigt es ein ungeheuer starkes Bedürfnis der Anwender: man kann sich seine überschaubar kleine und hübsch verpackte Anwendung downloaden und am Mobiltelefon ablegen.

Plötzlich sind nicht nur Dateien handlich, sondern auch Programme!

Inzwischen drängen Microsoft (Apps Gallery), Apple (Mac App Store), Intel (AppUp) und Google (Chrome Web Store) auf den Markt der Desktops. Google geht sogar noch einen Schritt weiter und schreibt drumherum mit Chromium OS ein eigenes Betriebssystem. In Wien gibt es mit Wappwolf ein mMn visionäres Unternehmen, welches mit einem Appstore-artigen Konzept Dateien-Verarbeitung in der Cloud anbietet.

Das Internet als Supermarkt. Software geschnitten, gewaschen, zum sofortigen Verzehr geeignet. Foto: Mathias, Brunei Darussalam 2010

Hintergrund der Bestrebungen ist, wenig überraschend, ein wirtschaftlicher: Apps sind wahre Goldgruben. Der aktuelle Goldrausch lässt wohl sogar Drogenkartelle und andere Pharmafirmen in Neid erblassen.

Apple als Marktplatz bzw. Händler kassiert beispielsweise 30% der Umsätze im App Store – bei nicht existenten mengenabhängigen Kosten. (Oder ist dort schon mal eine App wegen mangelnder Kühlung verfault? Musste jemals jemand eine App wegen einem Lieferschaden umtauschen?)

Unter dem Deckmantel deutlich gesteigerter Usability werden Programme folglich vermehrt über Marktplätze angeboten. Dabei geht ein Großteil der Anstrengungen der Betreiber – technisch wie juristisch – in den Aufbau von Barrieren, wie etwa Kopierschutz oder Softwarepatente. Während wir uns also über teilweise lächerliche Updates freuen (Copy & Paste in iOS 3.0), gehen unsere Desktops einen zumindest zweifelhaften Weg:

Zuerst wurden unsere Mobiltelefone beinahe zu Computern. Jetzt werden unsere Computer zu Smartphones – großen “Einkaufscomputern”.

Wenn die Systeminterna (Dateisystem, Prozesse) einmal weg-abstrahiert sind, kann man schließlich nur noch auf das “Kaufen”-Symbol klicken/”touchen”. 1950 konnte sich wahrscheinlich keine Hausfrau vorstellen, Salat geschnitten, Eier gekocht und Erdäpfel püriert aus dem Supermarkt zu holen. In deutlich kürzerer Zeit werden wir aber für das Rotieren eines Bildes um 90° rechts oder das Anhängen eines Attachments in eine E-Mail bezahlen. Klingt erschreckend, aber wir werden uns schon daran gewöhnen. Außerdem, es wird ja nur ein paar Facebook Credits kosten und das Umrechnen in Euro tut sich ja eh keiner so gern an…

Tags , , , , | Permalink | Comments (4)
hacks

Interactive Digital Signage with MS Kinect

July 20, 2011 – 2011-07-20 4:31:22

Despite the high bullshit to fact ratio SIME Vienna was fruitful as Florian Dorfbauer (LaGentz) and I came up with the idea of using Microsoft’s Kinect as a controlling device for public user interfaces.

At WU Wirtschaftsuniversität Wien we’re throwing the current course schedule on large screens. Given the fact that we have up to two hundred courses in the list but – in contrast to airports – only a limited budget for the task the students are presented a slideshow rather than an array of expensive displays. You can imagine that it’s quite boring to watch the screen for a few minutes until your content appears…

Enough of background talk, here’s a video of the prototype solution.

What next?

The nice thing about the proof of concept is that it uses a web browser for content display. So anything can be displayed. The commands from Kinect are entered into the browser as key strokes (thus no browser APIs, compilation, or anything involved).

The challenge from here will be twofold: First we still need a user interface that automatically explains the  interaction possibilities to the user. Second, the Kinect is a brandnew device designed for your living room. So we have no data on its durability out in the field…

Tags , , , , , , | Permalink | Comment (1)
meta

Was machen eigentlich Programmierer?

July 11, 2011 – 2011-07-11 2:23:39

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…

Tags , , , , , | Permalink | Comments (3)