stimulanzzirkel

Information

This article was written on 07 Mar 2013, and is filled under out of time.

Onlinesoftware Projektmanagement

Folgende vier Themencluster, die ich euch unten etwas näher beleuchte, werden in Zukunft eine größere Rolle im Feld der Onlinesoftwareentwicklung spielen:

  1. Projektmanagement & Kollaborationswerkzeuge
  2. User Experience (UX) Design
  3. Mobile first! Responsive Design
  4. Web Mapping

Dieser Text versucht die Cluster überblicksartig darzustellen und verwendet hoffentlich eine niederschwellige Sprache, um auch den dem Programmieren “Außen-stehenden” das Verständnis zu ermöglichen. Im Endeffekt ist dieser Text eigentlich nichts anderes als eine stark kommentierte Linkliste, die sich am Ende des Dokuments befindet.

 

__1__Projektmanagement & Kollaborationswerkzeuge

 

 

Wenn ich dieser Tage mit Herstellern von sog. Webanwendungen (z.B. Toggl, Trello) spreche, wird auf zukünftige Features meist mit “It’s done, when it’s done.” Bezug genommen. Scheinbar gibt es keine zeitlich definierte Roadmap mehr, welche Meilensteine definiert, zu denen bestimmte Entwicklungen abgeschlossen sein müssen.

Dies ist eine der ersten Besonderheiten bei der Entwicklung von Onlinewerkzeugen : es gibt keinen materialistischen “Redaktionsschluss”, kein Lieferdatum, zu dem eine physische Kopie eines Produkts ein Presswerk, eine Fabrik verlässt. Woraus sich neue Vorbedingungen der zeitlichen Organisation eines Projekts bilden.

So verändert sich die Arbeitsweise der Softwareindustrie seit Jahrzehnten hin zu iterativer Entwicklung – pers könnte meinen, eine zyklische Zeitvorstellung gewinnt gegenüber der klassisch/modernen westlich-europäischen linearen. In Buzzwords spricht man von “Agile Development”, sogenannten “Sprints” und “Scrum Boards”. Die Codeentwicklung wird zum beständigen Spiel mit dem Istzustand und erfordert Leidenschaft und Kontinuität.

Den Wissenschaftlern unter uns dürfte dies in Form der Methode des hermeneutischen Zirkels [01] bekannt vorkommen : analysieren + identifizieren, korrigieren + gestalten, zusammenfassen + evaluieren. Wiederholen.

 

Auf Stack Exchange habe ich eine schöne Frage gefunden [02], die uns einen guten Einstieg in die technische Seite des Themas gibt, auch wenn sie für’s Erste etwas überbordend erscheinen mag. Der Hund liegt wie so oft im Detail begraben!

Stack Exchange ist ein Diskussionsforum für codeaffine Menschen, welches binnen kürzester Zeit auf Grund qualitativ anspruchsvoller Diskussionen hohe Popularität erreicht hat. Ich möchte im Besonderen auf die Antwort von “haylem” mit 355 (6.3. / 17:44) Stimmen eingehen.

 

Kurz vorher aber noch eine Erläuterung wichtiger technischer Mittel:

SCM / VCS – Source Control Management / Version Control System [03]

Versionierungssysteme werden dafür eingesetzt den Zustand des Codes für bereitgestellte Zeitpunkte jederzeit wieder herstellen zu können. Sie dienen der zentralen Ablage von Codebestandteilen und erlauben mehreren Benutzern den Zugriff. Häufig integrieren sie auch ein Bug Tracking System. Größte Stärke der VCS ist das Branching genannte Verfahren, bei dem parallele, auf einander bezügliche Codestränge eigenständig entwickelt, durch Merges aber wieder vereint werden können [04].

Bug Tracking / Issue Tracker

Fehlerverfolgungssysteme werden eingesetzt, um den Zustand von Ungereimtheiten im Code verfolgen und besser beheben zu können.
Populäre Beispiele hierfür sind Trac [05] oder Mantis [06], aber auch GitHub (u.ä.: Bitbucket, Sourceforge, …) [07] stellt einen Issue Tracker bereit. Trello [08] lässt sich ebenfalls mit etwas Phantasie in solch ein System verwandeln. Diese Werkzeuge müssen auch nicht immer Augenkrätze produzieren, wie die beiden letztgenannten beweisen.

Continuous Integration (CI)

CI meint bei Projekten in Programmiersprachen deren Code vor Ausführung in Maschinensprache übersetzt wird (Kompilierung, Übersetzung, Zusammenstellung) diesen Vorgang auf Basis des immer aktualisierten Codes in der Versionsverwaltung beständig in definierten Zyklen zu wiederholen, um bereits währenddessen Fehler automatisch erkennen zu lassen.

 

Die für uns interessanten Abschnitte der Antwort von “haylem” dienen als Gliederungsvorlage für die Bereiche Projektstruktur, Konventionen & Flexibilität, Dokumentation, Werkzeuge und Überprüfung. Übereinkünfte unter Entwicklern einer gegebenen Anwendung in eben diesen Bereichen können dabei helfen Irritationen zu vermeiden und das Gesamtprojekt flüssiger voranzubringen.

Projektstruktur

Für Codeprojekte dienlich ist es alle Beteiligten frühzeitig Gewissheit erlangen zu lassen, welche Schritte als nächstes durchzuführen sind. Dies impliziert ein strukturiertes Projektmanagement, welches sich womöglich bestimmter Methoden (Agile, Scrum) bedient, zumindest aber eine nachvollziehbare Organisationsstruktur prägt und gegenseitigen Austausch fördern kann.
Jede_r hat für solche Rahmenbedingungen eigene Erfahrung, die sie_er in den Prozess einbringt. Pers spricht auch von “Best Practice” Beispielen, welche sich als Kategorisierungen der Arbeitsschritte bewährt haben. (vgl. [09] und [10] )

Konventionen & Flexibilität

Die durch solche “Best Practice” Beispiele propagierten Konventionen stehen gleichzeitig in einem Spannungsfeld mit gebotener Flexibilität des Entwicklungsprozesses. Hierbei ist zwischen der rigiden Anwendung einer Regel und seiner losen Interpretation, frei nach dem Motto “Practicality beats Purity” [11], abzuwägen. Es bleibt festzuhalten, dass die Einhaltung vorher definierter Standards, als Problemlösungsstrategie verstanden, einem Werkzeuge an die Hand gibt, um auftretende Sachverhalte gezielt und effizient bearbeiten zu können.

Dokumentation

Nichtsdestotrotz ist ein gerne unterschätzter Bereich der Projektdurchführung die Dokumentation. Hierbei ist zu unterscheiden zwischen (semi-)automatischen Vorgehensweisen der Entwicklungs- und einer Endanwenderdokumentation. Letztere baut auf der vorhergehenden auf, denn woher wüsste man sonst, was das eigene Programm kann, und es soll nur erwähnt werden, dass hierfür gerne kollaborative Wikis, Google Docs, Etherpad oder Dokumentenmanagementsysteme eingesetzt werden, damit Code und Dokumentation stets auf einem Stand sind.

Codekommentare dienen zum einen der bequemen Navigation im Code und erleichtern nachfolgenden Programmierern, wie einem selbst, auch das Verständnis, da pers gezwungen wird zu beschreiben, worauf die programmiersprachlichen Algorithmen abzielen.
Bei der Verwendung eines (verteilten) Versionskontrollsystems empfiehlt es sich bspw. frühzeitig und häufig dessen Dokumentations- und Backupfunktion zu nutzen, da für jeden eingebrachten Codeblock (Commit) auch ein Kommentar angefügt wird. Aus der Sammlung der Patches entsteht dann automatisch das Protokoll. “Check-in / commit / branch / merge early and do so often.”

Werkzeuge

Jede_r Entwicker_in hat ihren_seinen eigenen Stil, eigene Gewohnheiten und verwendet routiniert die in der Vergangenheit angelernten Werkzeuge. Es soll niemand zur Verwendung bestimmter Anwendungen gezwungen werden, wenn es vergleichbare Angebote gibt, doch sollte sichergestellt sein, dass alle Bestandteile einer Entwicklungsumgebung (auf überpersonellem Niveau) gut zusammenarbeiten und einen geringen Wartungsaufwand haben. In der Branche werden gerne integrierte Entwicklungsumgebungen (IDE – Integrated Development Environment) eingesetzt, welche standardisierte Vorgehensweisen in einer interaktiven Benutzeroberfläche umsetzen. Hierzu gehört mitunter auch das Zusammenspiel mit Versionierungs-, Kompilierungs- und Bug-Tracking-Systemen.

Überprüfung

Die Überprüfung der Codequalität kann automatisch durch CI-Systeme (s.o.) durchgeführt werden, ersetzt aber nie menschliches Peer Review. Wie bei Veröffentlichungen in wissenschaftlichen Journals, ist es bei der Übernahme von Code einzelner Entwickler in den Hauptentwicklungsstrang ebenso üblich, dass deren Code eine Kontrollinstanz passieren muss, welche auf letzte übersehene Fehler und die Einhaltung der definierten Konventionen prüft. Auch ist es unerlässlich den Code “live” zu prüfen, d.h. Anwender am fertigen Produkt arbeiten zu lassen und deren Erfahrungen zu notieren (Usability Tests).

So verstehen wir das Programmieren als sozialen Vorgang, der nie außerhalb menschlicher Gemeinschaften stattfindet. Es hat sich gezeigt, dass Teams, welche sog. “Coding Buddies” [12] enthalten, seltener fehleranfälligen Code produzieren, da es eine Austauschplattform für Fragen und Probleme gibt, auf die sich der vor der Maschine tippende Mensch beziehen kann. “Pair Programming” oder verwandt “Extreme Programming” sind gängigere Bezeichnungen dafür.

Spannend ist jedoch zu beobachten, wie dezentral in Remotearbeit organisierte Teams die Kommunikationshürden gegenüber Büroarbeit [13] [14] mit technischen Mitteln zu überbrücken wissen. Nicht ohne Grund stehen uns heute hochentwickelte Kollaborationslösungen zur translokalen Projekt- und Codebetreuung zur Verfügung.

All diese Vorkehrungen haben nur ein Ziel : eine höhere Codequalität. Wofür sich kein_e Coder_in schämen muss und ein_e passionierte_r Entwickler_in selbstredend interessiert. Schließlich ist pers nicht einfach nur “die Person die den Code in die Maschine hackt” [15] [16], sondern vielmehr Architekt von Systemen, Designer von Benutzeroberflächen und Gestalter von (Nutzer-)Gemeinschaften. Durch das Medium Code.

Viele der hier vorgestellten “Best Practice” werden bspw. wunderbar durch GitHub [07] unterstützt.

 

Eine Überschrift aus der “hayem” Antwort möchte ich doch noch hervorheben:

_____But What if My Code is Already Crap?_____

Dazu passt auch ein Text von Joel Spolsky (Trello / Stack Exchange CEO) [17], der im selben Beitrag etwas weiter oben verlinkt ist. Ein paar Auszüge:


It’s harder to read code than to write it.


When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.


It’s important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time.

Somit bin ich an diesem Punkt zwiegespalten, was bestimmte Situationen angeht : doch lieber eine Neuentwicklung der gesamten Codebasis, in Grundzügen an das “Original” angelehnt, oder perpetuelle, gezielte Verbesserung der erwiesenermaßen stabilen, vorhandenen Codebasis?
Das muss letztendlich wohl jeder für sich entscheiden.

 


Famous Last Words, and Humble Requests:

Document everything you do.
Share your experience.
Open Source any tool your write.

 

[01] Wikipedia : Hermeneutischer Zirkel
[02] Stack Exchange : Diskussion über das Erbe von Code
[03] Wikipedia : Versionsverwaltung

[04] Streamed Lines : Branching Patterns for Parallel Software Development

[05] The Trac Project
[06] Mantis Bug Tracker
[07] GitHub
[08] Trello

[09] Interview Guide : Small Business + Web Standards
[10] Launchlist

[11] The Zen of Python

[12] Jeff Atwood (2009) : Who’s your Coding Buddy?
[13] David Fullerton (2013) : Why We (Still) Believe in Working Remotely
[14] Jeff Atwood (2010) : On Working Remotely

[15] Patrick McKenzie (2011) : Don’t Call Yourself A Programmer, …
[16] Jeff Atwood (2006) : Egoless Programming : You Are Not Your Job

[17] Joel Spolsky (2000) : Things You Should Never Do, Part I

 

__2__UX Design

 

Nachdem ich im Vorfeld ausführlich über Projektmanagement und Kollaborationswerkzeuge geschrieben habe, möchte ich kurz ein neues Fenster öffnen, das nicht allen Softwareentwickler_inne_n, welche doch einen Hang zur Ästhetisierung des technischen Aspekts ihrer Disziplin haben, gleichermaßen wichtig ist. Ich spreche vom User Experience (kurz: UX) Design.

In der realweltlichen Umwelt von Softwareprojekten treten ebenso ökonomische Aspekte recht barrierelos in die Aufmerksamkeit : wenn Personen eine große Anzahl an Stunden vor dem Bildschirm investieren, muss gleichzeitig ihre Überlebensfähigkeit gesichert sein. Dies geschieht entweder durch einen ausgeklügelten Austausch und Abhängigkeitsverhältnisse mit Mitmenschen (Familie, Wohnprojekte einschl. WGs, Subsistenzwirtschaft, …), besondere Arbeitsverhältnisse, die diesen Freiraum eindenken, oder eben durch das Medium Geld.

Und wenn das Ergebnis der eigenen Arbeit sich wirtschaftlich tragen muss, sollte das Produkt auch anständig vermarktet werden. Und damit es auf dem Markt bestehen kann, will es dem Nutzer (User) ein angenehmes Erlebnis (Experience) verschaffen. So einfach die Rechnung dahinter.
Und die gesamte Erfahrung geht schließlich weiter als schlichtes UI (User Interface) Design.

ISO 9241-210: “Prozess zur Entwicklung gebrauchstauglicher interaktiver Systeme” [20] ist ein, sic, prozessorientierter Ansatz, der Entwicklung und Anwendung gleichermaßen umfasst. Diese Welt erscheint manchmal ein bisschen esoterisch (“Was impliziert ‘Erleben’?” [21]), basiert dabei aber auf klaren Gedanken:


Dabei muss aus unserer Sicht mehr Wert auf das explizite Formulieren zugrundeliegender gestalterischer Prinzipien gelegt werden. Gestaltungsprinzipien sind immer normativ. Sie sind mehr oder weniger willkürliche Setzungen des
Gestalters, die aber das Gestaltungsergebnis stark beeinflussen. Daher sollten sie gut überlegt sein. Trotzdem darf aber nicht die Frage nach “richtigen” oder “falschen” Prinzipien im Vordergrund stehen, sondern eher die Frage, ob Prinzipien in einem Entwurf auch stringent angewendet werden und inwiefern sie nützlich, d.h., generativ und inspirierend sind.

[ebd., Hervorhebung im Original]

Letztlich muss jede_r Praktizierende selbst wissen, was für sie_ihn wichtig ist, wie im Kapitel zuvor. Es scheint tendenziell eine Übereinkunft dahingehend zu geben, dass standardisierte, definierte, strukturierte Arbeitsweisen ein klareres, interoperableres Produkt, nicht nur auf technischer, sondern auch auf sozialer Ebene zur Folge haben.

Ich werde nicht ins Detail gehen und meine weiteren Gedanken dazu ausführen, welche selbst noch in ihren Kinderschuhen stecken, möchte nur auf das Themenfeld hinweisen, um für die Zukunft den Horizont zu erweitern.

Die wenigen praktische Ressourcen zum Thema, die ich kenne, finden sich bspw. auf dem Blog von Mette Walsted [22], einer UX | UI Designerin aus Kopenhagen, oder beim Smashing Magazine [23]. Ansonsten kann ich bislang auch nur auf den Wikipediaartikel [24] oder diverse Überblicksseiten [25] [26] [27] verweisen.

 

[20] Usability und User Experience unterscheiden
[21] Hassenzahl, M.; Eckoldt, K.; Thielsch, M. T. (2009): User Experience und Experience Design – Konzepte und Herausforderungen. in: H. Brau et al. (Hrsg.): Usability Professionals 2009 (S. 233 – 237). Stuttgart.

[22] Mette Walsted : UX Bleeps
[23] Smashing Magazine : Category : UX Design

[24] All About UX
[25] User Experience – UX Design – What Matters To Interaction Design Professionals
[26] UXmatters :: insights and inspiration …

 

__3__Mobile first! Responsive Design

 

Nicht nur Smartphones oder Tablets, sondern eine Vielzahl an mobilen Geräten mit unterschiedlichen Bildschirmauflösungen bevölkern den Markt, d.h. unsere Hosentaschen, Küchentische und Arbeitsplätze, darunter auch sehr große Bildschirme bei Desktops, sehr kleine bei Netbooks usw.

Wenn das Design einer Webseite sich an das Ausgabegerät anpasst, hilft dies den Nutzern dabei gesuchte Information schneller zu finden und möglicherweise sogar eher ihren Peers (mit) zu teilen. Darum geht es doch am Ende : virales Marketing um die Anzahl der Benutzerinteraktionen zu erhöhen, damit vielleicht sogar schließlich einmal der entscheidene Knopf gedrückt, die entscheidende Veranstaltung besucht wird, wobei Kosten oder halt Einnahmen generiert werden.

Einige Daten zu den Auswirkungen von mobilen Endgeräten auf die Nutzung von Webseiten finden sich bei LukeW [30]. Um auf die Bedeutung dessen für das Design von Webanwendungen hinzuweisen, möchte ich, dieses Kapitel abschließend, gerne einmal mehr die wunderbare List Apart [31] zitieren:


Design systems, not screens

More than half of U.S. laptop owners now also own a smartphone, and nearly a quarter of them own a tablet too (source). And, of course, with the holiday season past us, the number of users who own a device in all three categories will jump higher still. Users move between devices so fluidly, and in patterns that we often can’t predict. Now apps are starting to connect to other devices to control, synchronize or extend an experience.

I think we’re going to see more cross-channel design thinking in 2013 to address simultaneous multi-device usage, and frequent device hopping in a single workflow. Continuity between platforms will be important, but we don’t need to make the experience the same between devices. The user experience will morph with each context. We’ll need to design systems, not screens, to solve cross-channel experience design problems.

Dass die Ausrichtung der Entwicklung hin auf unterschiedliche Bildschirmgrößen möglichst frühzeitig geschehen sollte, brauche ich hier sicher nicht mehr zu erwähnen, oder?

 

[30] Impact of Responsive Designs

[31] A List Apart : Aaron Walter. in: What We Learned In 2012

 

__3__Web Mapping

 

Sodass wir endlich, nach meiner mehrstündigen Schreib- und Recherchereise, endlich bei dem Thema angekommen sind, von dem ich vergleichsweise noch die größte eigene Erfahrung besitze: Online Kartographie!

Die Zeit von Google als alleinigem Anbieter von Webkarten sind vorbei. Es gibt sehr viele, sehr ansehnliche (kommerzielle) Applikationen, welche Stück für Stück mehr Aufmerksamkeit generieren. Nicht nur durch veränderliche Stileigenschaften, sondern auch durch die Einbindung alternativer Kartenbibliotheken (allesamt Open Source zur freien Bearbeitung und Verwendung) oder die Darstellung von Echtzeitdatenquellen, werden diese interessant. Vielfalt vermag immer auch speziellere Bedürfnisse zu befriedigen.

Hervorzuheben sind hierbei, sozusagen als Komplettpakete, MapBox mit ModestMaps [40], CloudMade mit Leaflet [41], nicht zu vergessen CartoDB und CartoSet von Vizzuality [42]. Alternativen Implementationen von Web Mapping ist natürlich auch ein Platz einzuräumen, da sie für konkrete Szenarien sicherlich die bessere Wahl darstellen. Diese stützen sich nicht auf die als “Slippy Maps” bekannte Technik, die auch hinter Google Maps steckt und das beständige Nachladen von Kartenkacheln zur folge hat, sondern auf Vektordatenquellen unterschiedlichster Art.

Kartograph rechnet PostGIS Daten und Shapefiles in das offene SVG Format, bevor sie wunderschön dargestellt werden [43]. Polymaps [44] ist ein spannender Ansatz, der Kartenkacheln und SVG Daten vereint darstellt, wohingegen Cartagen [45] die OpenStreetMap Daten gleich ganz als SVG rendert. Beeindruckend!

Wen dieses Thema weitergehend interessiert, kann mich gerne anschreiben oder einen Kommentar hinterlassen. Aus der Recherche für die Berliner Gartenkarte [46] fliegt da noch eine zehnseitige Linksammlung zu GFOSS (Geospatial Free and Open Source Software) bei Google Docs herum. Diese erstreckt sich über Grundlagen, wie Datenquellen und technischen Standards, über Client- und Serveranwendungen bis hin zu Implementierungen und Präsentationen.

 

[40] MapBox
[41] CloudMade
[42] Vizzuality Products

[43] Kartograph Showcase – La Bella Italia
[44] Polymaps
[45] Cartagen

[46] Berliner Gartenkarte

 

Nun, aber ran an die Bouletten und losjehackt!

 

Mehr gibt’s demnächst von mir über Onlinekollaboration im Blog der Initiativen 2.0 [50] Forschung.

Lasst’s euch gut geh’n – ich muss die ganzen Projektchen jetzt auch mal ruhen lassen.

j*

almereyda.de [51]

 

YouTube Preview Image

 

Und da heute noch nicht genug Links geklickt wurden : was zum Spielen! [52]

 

[50] Projektverbund Initiativen 2.0 – einForschungsprojekt zu zivilgesellschaftlichem Engagement und Web 2.0
[51] almereyda – semantic network design
[52] PuzzleDrag

 

Quellen:

 

Abschnitt I : Projektmanagement & Kollaborationswerkzeuge

[01] http://de.wikipedia.org/wiki/Hermeneutischer_Zirkel
[02] http://programmers.stackexchange.com/questions/155488/ive-inherited-200k-lines-of-spaghetti-code-what-now
[03] http://de.wikipedia.org/wiki/Versionsverwaltung

[04] http://www.bradapp.com/acme/branching/

[05] http://trac.edgewall.org/
[06] http://www.mantisbt.org/
[07] https://github.com/
[08] https://trello.com/

[09] http://biz.webstandards.org/interview-guide/
[10] http://lite.launchlist.net/

[11] http://www.python.org/dev/peps/pep-0020/

[12] http://www.codinghorror.com/blog/2009/02/whos-your-coding-buddy.html
[13] http://blog.stackoverflow.com/2013/02/why-we-still-believe-in-working-remotely/
[14] http://www.codinghorror.com/blog/2010/05/on-working-remotely.html

[15] http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/
[16] http://www.codinghorror.com/blog/2006/05/egoless-programming-you-are-not-your-job.html

[17] http://www.joelonsoftware.com/articles/fog0000000069.html

 

Abschnitt II : UX Design

 

[20] http://blog.procontext.com/2010/03/usability-und-user-experience-unterscheiden.html
[21] http://www.thielsch.org/download/Hassenzahl_UP09.pdf

[22] http://mettewalsted.dk/
[23] http://uxdesign.smashingmagazine.com/

 

Abschnitt III : Mobile First! Responsive Design

 

[31] http://www.lukew.com/ff/entry.asp?1691

[32] http://alistapart.com/article/what-we-learned-in-2012

 

Abschnitt IV : Web Mapping

 

[40] http://mapbox.com/
[41] http://cloudmade.com/
[42] http://vizzuality.com/products

[43] http://kartograph.org/showcase/italia/
[44] http://polymaps.org/
[45] http://cartagen.org/

[46] http://gartenkarte.de/

 

[50] http://www.ini20.de/
[51] http://almereyda.de/
[52] http://gmaps-samples.googlecode.com/svn/trunk/poly/puzzledrag.html

One Comment

  1. […] Beitrag zur Digitalisierung und dem Leistungsschutzrecht in der Berliner Gazette, und auf elektroni finden wir einen Artikel, der zwar etwas technisches Hintergrundwissen erfordert, aber spannende Perspektiven auf die […]

Leave a Reply