Tag Archives: software

IT project management

Campus WU: Drei Jahre in drei Minuten

Drei Jahre intensive (Projekt-)Arbeit, oder physikalisch ausgedrückt: Große Masse mal hoher Geschwindigkeit mal viel Weg.

“Man muß ins Gelingen verliebt sein, nicht ins Scheitern.”
Ernst Bloch

Door Signs

Über 200 Stück am gesamten Campus verteilt: Starten und aktualisieren sich über Netzwerk, gehen nachts schlafen, lesen Blinden die Belegung vor und kosten dabei ein Viertel der ursprünglichen Planung.

hj
61 der über 200 Displays vor Ort. Die angezeigte MAC-Adresse diente als Key bei der Inbetriebnahme.

Blogs dazu:

Self Service Terminals

Zehn Selbstbedienungsautomaten vor dem Study Service Center: Eine technische Herausforderung, barrierefrei, verbesserte Usability und – nach wahnsinnig stressiger Inbetriebnahme – inzwischen stabil.

bsfdb
Zwischenzeitlich haben tausende Studierende die Self Service Terminals im Library Center genutzt. (Sechs Terminals im Bild mittig; © Mathias August 2013)

Blogs dazu:

Final-Teilnahme beim Niederösterreichischen Innovationspreis.

Rooms

Dezentrale Raumbuchung für knapp 30.000 Benutzer_innen: Inhaltlich ist es Logistik pur samt dynamischer Lagerhaltung, Simulation, Statistik und passenden Visualisierungen. Rein technisch eine Herausforderung in JavaScript.

fff
Screenshot: User Interface der Raumbuchung für Studierende.

Blogs dazu:

Byte Bar und Leitsystem Terminals

fgfg fg
Die ByteBar- und Leitsystem-Terminals vor der Montage am Campus WU; Codename “Super-Toblerone”.

Surfstationen mit Login mittels berührungsloser Karte; Touchschirm, barrierefrei. Das Schwesterprojekt “Leitsystemterminal” dient zur Orientierung am Campus.

Blogs dazu:

API

gsg
Digital Signage Screens, die prominentesten Kunden unserer Lehrveranstaltungs-Daten API.

Viele unserer Daten sind – auch öffentlich – über Programmierschnittstellen verfügbar. So greifen alle hier beschriebenen Services auf dieselben Daten zurück, überall liest dieselbe Stimme Blinden vor, überall läuft dieselbe Logik, das Design ist gleich: managing complexity eines übergroßen Projekts eben.

Identmedien RFID

Eine Studierende holt sich einen Ausweis, verschließt ihre Sachen in einem der 3.600 Spindkasteln, bezahlt anschließend bargeldlos in der Mensa und öffnet einen gebuchten Projektraum: Keine Selbstverständlichkeit, läuft aber (immer besser).

Campus GIS

Geo-Informationssystem des Campus WU: Verortung von Personen und Organisationen, Suche nach POIs, Modellierung eines Routingnetzwerks zur Navigation, Flug einer Drohne für hochauflösende Luftbilder. Tool live: gis.wu.ac.at

Detaillierte Pläne, Suche, Routing bis hin zum Buch
Im Screenshot: Detaillierte Pläne der Regale zum Auffinden von Büchern in der Universitätsbibliothek.

Thanx + Uff!

Gerne würde ich hier behaupten, ich hätte das Alles programmiert, habe aber dann doch oft nur E-Mails geschrieben oder bin in endlosen Meetings gesessen. Ich musste langweilige Ausschreibungstexte querlesen, extern erdachte Konzepte ertragen, Kostenschätzungen durchs Haus schicken, Ideen verteidigen und am Widerstand Dritter scheitern sehen… Vier Befestigungsschrauben meiner Terminals kosteten mich so ein halbes Jahr Abstimmungsaufwand.

Als im Feuer getaufter Planerschlossertischlerdesignerentwickler kann ich nun verorten, kollaudieren, ausschreiben, beschaffen, eintakten, einbringen, einkippen, und Katzen hüten. Ich habe am Weg viele beeindruckende Menschen kennengelernt und dafür bin ich dankbar.

Es war ein Heidenspaß, ein Riesenstress und manchmal auch ein Mordsärger, vor allem aber war’s einzigartig und großartig. Wann und wo wird also der nächste Campus gebaut?

hacks

Project visualization with redesigned Gantt charts

When reading the Edward Tufte forum on Project Management Graphics I was surprised (and relieved) that a lot of people seem to have their problems with Gantt charts and their doubtful usefulness for project management.

After some thoughts on the topic I’d like to present my proposal for visualization of project flows. In case it matters: I’m currently part of a half a billion Euro construction project in Austria.

The real world example

The image below shows one Gantt chart of the project I’m currently involved in.

dfgh
Actual Gantt chart of “my” current project.

Aside from its professional look it transports surprisingly little content. My main points of criticism are:

  • On the one hand, with more than a hundred tasks on the left I get overwhelmed by things I’m not responsible for anyway.
  • On the other, my 15 tasks lack important detail.
  • Since it’s not possible to combine overview with sub-project specific detail I have to manage my tasks in parallel.
  • I easily lose track between tasks and the bars on the far right. Gridlines would be a bad idea as well since they add too much clutter.
  • Data is sparse and the chart needs too much space for the presentation thereof.
  • In my context of software development the chart’s implicit focus on sequential, waterfall-like project flows does not fit my reality of ever-changing project plans.
  • I definitely need to print it out to be able to use it.

What would I need?

First of all: Everybody can read a Gantt chart so let’s stick to some reasonable habits: bars that encode project duration by length and diamond symbols that mean milestones, i.e. important dates.

When I think of project management, the whole story is about one core task: Align your output and handover dates with those of others.

As a member of any project team I simply cannot be interested in the task of each individual. However the Gantt chart’s focus lies on the presentation of single tasks. I state that any visualization for project management should focus on people or teams, i.e. responsibilities, rather than tasks.

My second point revolves around overview and detail: My own tasks should be presented in greater detail than data of other teams. My only concern with them is deliverables when we approach mutual handover dates.

The Redesign

Here’s some example data taken from one of my schedules:

Responsible Task Start End
Construction Define location Sun Jan 01 2012 Sun Apr 15 2012
Construction Finish site Thu Aug 01 2013 Milestone
IT Develop prototype Sun Jan 15 2012 Sat Jun 02 2012
IT Testing Sun Jun 03 2012 Sun Jul 01 2012
Business Process Give feedback Sun Jun 03 2012 Sun Jul 01 2012
Supplier Deliver parts (prototype) Thu Mar 01 2012 Sun Aug 05 2012
IT Update integration Sun Jul 01 2012 Tue Aug 14 2012
IT Evaluate prototype (hands-on) Wed Aug 15 2012 Mon Oct 01 2012
IT Evaluate prototype (remote monitoring) Tue Oct 02 2012 Wed May 01 2013
IT Production Mon Aug 19 2013 Wed Jan 01 2014
Business Process Launch prototype environment Wed Aug 15 2012 Milestone
Business Process Go live Mon Aug 19 2013 Milestone
Procurement Procure Mon Apr 01 2013 Wed May 01 2013
Supplier Deliver parts (production) Wed May 01 2013 Mon Aug 12 2013

Classic Gantt chart

And here goes the corresponding Gantt chart:

srg
Gantt chart encoding the tabular data above. (Written in JavaScript).

My version, aka: Gantt90

My enhanced version is shown below. Instead of single tasks I only show the responsible team. Additionally I rotate by 90 degrees – thus Gantt90 – to shift the attention from process flow to responsibility, from a mechanical point of view to a more social one if you want to put it like this.

While the information conveyed is almost equal, the charts size is halved. Hence even the thumbnail becomes readable.

dsf
Proposed redesign of a Gantt chart: teams instead of tasks and rotation by 90 degrees.

Adding detail

Since I’m a member of IT, the two blue bars on the right should now convey more information than the others. I do that by highlighting my team and showing the specific tasks along the time axis. Enough detail for the team, and I manage to simultaneously keep track of other teams’ schedules.

sd
Overview and detail combined. The chart could even be made recursive with sub-teams of IT on the right. (…)

Thinking of my big example from the beginning it will be necessary to further divide the detail view on the right. Since projects – tasks as well as teams responsible – fit into hierarchical, tree-like data structures my chart would recursively expand to the right. (IT would then be divided into developers, testers, administrators, etc. and the new chart would resemble its left neighbour – both aligned with the common time axis.)

What about connecting lines?

You may have noticed that I skipped the connecting lines between the taks. I’m convinced that a proper visualization should signalize the project’s inherent structure on its own. Even if the lines are not there, you can see the dependencies between tasks and/or milestones anyway. Your brain does quite a good job at pattern recognition.

tldr: Like spreadsheets, Gantt charts are used to visualize business fiction rather than to manage projects. I’ve proposed a modified Gantt chart to better visualize projects by drawing attention to responsibility rather to single tasks.

Thanks to Elena Reitman’s tweet I stumbled upon the Tufte forum.

I highly recommend the book Envisioning information by Edward Tufte. The charts and the source code used can be found here.

finance hacks

Python stock quote fetch

UPDATE

— 8< —

Nach den heldenhaften Ideen des ebenso heldenhaften Stefan twittert nun mein Portfolio wochentags um 15:00 die aktuelle Entwicklung: crashportfolio@twitter

— 8< —

Anfang der Woche habe ich mein fiktives Krisenportfolio gepostet – damit war’s plötzlich höchste Zeit, Kursentwicklungen aktuell zu halten. Zwei Stunden und ein paar Zeilen Python später ist nun alles automatisiert.

Natürlich ist die Verwaltung eines Portfolios etwas, was Yahoo!, Google und zig andere Dienste gratis anbieten. Außerdem sehe ich die Positionen ohnehin auf meinem Konto bei brokerjet, aber dennoch: Nichts macht so viel Spaß wie eine selbst gebastelte Lösung, nichts ist so flexibel verwendbar, und nichts geht abzüglich der anfänglichen Programmierzeit danach so schnell.

Erfassen

Zunächst war es wichtig, die fiktiven Investments strukturiert zu erfassen. Ich hasse zwar Tabellenkalkulation, aber CSV scheint dennoch ein brauchbares Austauschformat zu sein. Kurzum: Name, Einstiegskurs, Menge, Datum, sowie eine ID (=Symbol) und ein Pointer auf den jeweiligen data provider sind wichtig.

Commodity ETF,etf/RBS_Market_Access_Jim_Rogers_International_Commodity_Index_ETF,26.50,900,08.07.2012,finanzen.net
Altria,PHM7.F,28.51,300,08.07.2012,yahoo
BP,BPE5.DE,5.40,1400,08.07.2012,yahoo
Fuchs Petrolub,FPE.DE,40.80,180,08.07.2012,yahoo
Nestle,NESR.DE,48.64,150,08.07.2012,yahoo
Novo Nordisk,NOVA.DE,118.32,65,08.07.2012,yahoo
Pfizer,PFE.DE,18.21,400,08.07.2012,yahoo
Shoprite,HY7.F,15.64,480,08.07.2012,yahoo
Umicore,UMI.BR,35.32,200,08.07.2012,yahoo

Absaugen

Das CSV-File wird mittels Python eingelesen, die Klasse Paper wird pro Position instanziiert. Yahoo! bietet ein unerschöpfliches API für Aktienkurse, die Python-Library ystockquote macht das Ganze sehr einfach zu verwenden.

class Paper():
    """Any bond, etf or stock"""
    
    def __init__(self, data_provider, name, symbol, quant, purchase_price, date):
        
        self.data_provider = data_provider
            
        self.name = name
        self.symbol = symbol
        self.quant = int(quant)
        self.purchase_price = float(purchase_price)
        self.date = date
        
        self._price = None
    
    def __repr__(self):
        return "%20s %7.2f %7.2f %7.2f%% %5d" % (self.name, self.purchase_price, self.price, self.change, self.totalgain)
    
    @property
    def price(self):
        if not self._price:
            
            if self.data_provider == 'yahoo':
                self._price = float(ystockquote.get_price(self.symbol))
            elif self.data_provider == 'finanzen.net':
                self._price = FinanzenNetParser.get_price(self.symbol)
            else:
                raise NoDataProvider
        return self._price

    @property
    def change(self):
        return ((self.price / self.purchase_price ) - 1) * 100
    
    @property
    def totalgain(self):
        return self.change / 100.0 * (self.purchase_price * self.quant)

Für den Kurs des ETF benötige ich einen HTML-Parser, da Yahoo! dessen Kurs nicht anbietet. Mit BeautifulSoup habe ich einen neuen Lieblings-Parser ins Herz geschlossen – in Kürze war also der Kurs von finanzen.net eingebunden. (Python-Tipp: Webscraping with Python and beautifulsoup)

Natürlich muss ich das auch noch für die Goldmünzen und die Uhr machen, die sich ebenso in meinem Portfolio befinden.

class FinanzenNetParser():
         
    @classmethod
    def get_price(self, path):
        """Ok, tricky: price is the first th in a table.header_height"""
        
        url = 'http://www.finanzen.net/%s' % (path,)
        content = urllib2.urlopen(url).read()
        
        soup = BeautifulSoup(content)
        for table in  soup.find_all('table'):
        
            if table.get('class') == ['header_height']:
                return float(table.th.text.replace('EUR','').replace(',','.'))

Ausgeben

Der Output ist derzeit noch etwas mager, mit Jinja2 sind die Daten aber schnell in HTML gegossen und auf meinem Mobiltelefon verfügbar.

                name purchase current  change  total
       Commodity ETF   26.50   26.57    0.26%    62
              Altria   28.51   28.79    0.98%    84
                  BP    5.40    5.48    1.50%   113
      Fuchs Petrolub   40.80   40.65   -0.37%   -26
              Nestle   48.64   48.86    0.45%    32
        Novo Nordisk  118.32  120.15    1.55%   118
              Pfizer   18.21   18.52    1.67%   121
            Shoprite   15.64   15.89    1.62%   121
             Umicore   35.32   34.65   -1.91%  -134

 

IT project management

Checklist Softwareauswahl

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.

hacks

CO2-Messung für Personenzählung

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.
ideas

Von Software-Qualität und Eisbergen

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.

IT explained meta

Von Dateien und der Zukunft des Internets

“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…

hacks

Interactive Digital Signage with MS Kinect

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…

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…