DEV Community: Michael Palmer

Rocket Deployment 🚀

Michael Palmer — Wed, 27 Jan 2021 13:59:09 +0000

Warning! This is an opinion.
This is the shortest article I’ve ever written.

Deploy early. Break things. Fix soon. Learn!

This isn’t new. Of course not. It is named agile. And we’re in the software industry doing it a lot. But unfortunately there is still a small barrier in mind of some old professionals who aren’t firm with the modern world, fast ci/cd pipelines and the comfort of live-issue-tracking like sentry is doing for us. All I like to say, I’ve already accompanied in a number of development teams and I felt very comfortable being early on production stage to grow together with the customers and stabilize features and functions. THAT DOES NOT MEAN that I think end customers are free testers and early adopters. OF COURSE NOT. Software should be well done, well tested, well documented and builded through a stable continuous integration pipeline. As devops says: build your application AND ship your application. We’re the designers of software and we know best how to run and fix it in critical situations. Rocket deployment means, for example, repair a feature, test it well and bring the fix as soon as possible back to your users. Never hold back finished code. It will be difficult to merge with every hour you’re behind the development branch!

Go out soon.

In App Verkäufe als Guthaben für Mehrwertdienste

Michael Palmer — Tue, 29 Dec 2020 19:10:46 +0000

Willkommen in der Mobile-Pay-World. Was ich damit sagen will?! Das Smartphone wird immer mehr zum Zahlungsmittel. Derzeit fliegen neue Produkte und Ideen aus allen Nischen der Softwaredienstleister. Auch Apple bietet jetzt mit Apple Pay die Möglichkeit, bargeldlos an Terminals zu bezahlen. Ich möchte hier einmal die “alten” Dienste von Google und Apple beleuchten und veranschaulichen, wie auch damit digitales Geld in Gutscheine oder Guthaben zur Nutzung von Mehrwertdiensten gewandelt und verifiziert werden kann.

Es geht um die Systeme In App Purchase (Apple) und In App Billing (Google). Diese Mechanismen wurden geschaffen, um “In App Käufe” zu ermöglichen. Gamer werden es am besten kennen. Für wenige Cents kann man sich Add-Ons wie Schwerter, Helme oder Gold und Ähnliches in den App Spielewelten aneignen. Apple oder Google bucht dabei den gewünschten Betrag von einem vorher verifizierten Zahlungsmittel des Mobilenutzers ab und transferiert diesen Betrag an den Betreiber (Entwickler) der App. Dabei erhalten Apple und Google üppige Provisionen. Diese Art ist derzeit üblich, um Apps wie Spiele scheinbar kostenlos anbieten zu können und die Kosten für Entwicklung und Betrieb der Software hinten herum durch kostenpflichtige Add-Ons wieder herein zu holen. Für bspw. Spiele funktioniert dieses Prinzip auch sehr gut. Nehmen wir an, wir entwickeln ein Autorennspiel. Dieses ist kostenlos in den Stores erhältlich. Der Spieler kann sich mit virtuellem Geld ein Auto kaufen, dieses neu lackieren und etwas aufmotzen. Anschließend fährt er damit Rennen gegen reale Gegner aus der Community. Er gewinnt und verliert. Verliert er zu häufig, braucht er dabei sein virtuelles Geld auf. Nun benötigt der Spieler aber einen leistungsstärkeren Motor. Dieser bedarf einer Summe X seines virtuellen Geldes, welches er aber bereits in den letzten Rennen verloren hat. Nun entschließt sich der Spieler den Motor für echtes Geld zu beschaffen. Die Kosten sind überschaubar, wenige Cents und er kann direkt weiter spielen. Jetzt haben wir als Herausgeber der APP zum ersten mal Profit gemacht. Verstecken wir viele dieser Möglichkeiten, neue Extras für das Spiel im Spiel zu kaufen, so erhöht sich dieser Profit und allmählich rechnet sich die Entwicklungszeit sowie der Betrieb unserer Server um das Spiel anbieten zu können.

Wie funktioniert der Kauf “In APP”?

Über einen Button wird das SDK von Apple (StoreKitSuite) oder Google (Google Wallet) geladen. Diese zeigen ziemlich ähnliche Dialoge an, welche dem Benutzer zunächst mitteilen, um welchen Kauf es sich handelt und was dieser kosten soll.

Im nächsten Schritt kann der Benutzer noch das Zahlungsmittel auswählen. Meist ist dies die bei Apple oder Google verifizierte Kreditkarte. Neuerdings kann man dort aber auch direkt über den Mobilfunkprovider oder weitere Zahlungsanbieter wie Paypal und ähnlichen bezahlen. Mit Bestätigen des Zahlungsmittels ist der Kauf bereits getätigt. Die App bekommt ein Verfiy-Signal, welches an unser Spiel zurückgegeben wird. Darauf können wir nun reagieren und das gewünschte Feature freischalten.

Der grobe Ablauf

Für beide Anbieter, Google und Apple, ist es möglich sich die Liste der verfügbaren Produkte zu einer App vom Server zu laden. Angelegt werden sie über die App Einstellungen. Für jedes Produkt wird eine eindeutige ID vergeben. Dabei ist es wie immer empfehlenswert die Reversedomain des Anbieters und einen Suffix zu wählen; bspw. de.entwickler.race.engine. Bei Google ist es nun möglich, einen genauen Kaufbetrag für das Produkt zu definieren. Apple grenzt den Spielraum hier etwas ein und lässt nur die Auswahl von Tiers zu, welche den Wert des Produktes in Staffeln definiert. Bei der Abfrage aller Produkte zu einer App erhalten wir nun also eine Liste der ID’s, welche potentiell gekauft werden können. Dabei unterscheiden beide Anbieter noch einmal in Produkte und Mieten, also Managed In-App Products und Subscriptions. Das rührt daher, dass diese Art Kauf für bspw. Abonnements gedacht ist. Beispielsweise kaufe ich mir den Service von Spotify für einen Monat. Für dieses Abo kann die App nun bei jedem Start prüfen, ob das Abo noch gültig ist. Wenn nicht, kann sie entweder den Nutzer dazu auffordern, das Abo zu verlängern oder dies sogar automatisch erledigen, sofern der Nutzer dem vorher zugestimmt hat.

Haben wir nun das entsprechende Produkt, welches wir verkaufen wollen, identifiziert, so können wir mit diesen Daten die Kaufmaske anzeigen. Bestätigt der Nutzer jetzt diesen Kauf, senden wir die Anfrage an den Verifizierungsserver des Anbieters. Anhand des Verifizierungs-Keys wird auf dem Server das Produkt und der Nutzer überprüft. Sind die Daten okay, antwortet der Server mit einem “Okay” in dem jeweiligen SDK Dialekt. Dies geschieht Synchron. Ist der Server also offline oder die Datenverbindung des Nutzers schwach, so kann es zu Problemen kommen. Dieses Offline-Problem wollen wir hier aber nicht näher betrachten. Zusätzlich senden beide Anbieter eine Signatur verschlüsselt durch den Key mit zurück an die App. Diese Signatur oder Nachricht kann dort dekodiert werden. Enthalten sind bspw. die Transaktions-ID und weitere Kaufrelevante-Informationen.
Hier endet das einfache Beispiel eines In App-Kaufes. Die App schaltet das Feature frei und der Nutzer zahlt mit seiner nächsten Kreditkartenabrechnung den Erhalt eines neuen Motors. Für diese Art von Kauf ist das Verfahren bestens geeignet. Jetzt kommen wir aber zum eigentlichen Thema, den Kauf von Guthaben für einen kostenpflichtigen Dienst.

Aufladen

Nehmen wir einmal das Beispiel einer Telefonie-App. In dieser können die Nutzer untereinander kostenlos telefonieren und chatten. Dies funktioniert direkt über die Datenverbindung, was den Anbieter dennoch die Bereitstellung der nötigen SIP-Infrastruktur kostet. Diese Nebenkosten geht er aber gerne ein, denn der eigentliche Dienst, welchen er seinen Kunden anbieten will, ist Dialout. Also der Anruf in das öffentliche Telefonnetz. Alle Gesprächsteilnehmer, welche nicht diese App benutzen, können nur über die echte Telefonnummer erreicht werden. Dieser Service kostet Terminierungsgebühren. Für ein ganz normales Telefongespräch zur Oma muss der Nutzer der App also bezahlen. Dafür benötigt er Guthaben auf seinem Konto. Dieses kann er über direkte Zahlungsanbieter in der App aufladen, dort wird es voraussichtlich wieder Paypal, Sofortüberweisung oder eine Wirecard-Schnittstelle geben. Oder, und dies führt uns zurück zu diesem Artikel, er nutzt die IAP- oder IAB-Schnittstelle direkt nativ des Smartphoneherstellers. Dabei haben wir als Herausgeber und Entwickler aber nun ein gravierendes Problem. Die Verifizierung einer Zahlung, bislang hier immer der Kauf eines Produktes genannt, wird NUR serverseitig bei Apple oder Google vorgenommen. Der Anbieter, also wir, erhalten niemals Auskunft über einen getätigten Kauf aus unserer App heraus. Wie können wir also nun in unserer Telefonie-Cloud einem Konto Guthaben aufbuchen ohne den Trigger zu erhalten, dass der Inhaber des Kontos gekauft hat? Zur Lösung dieses Problems wenden wir einen kleinen Umweg an. Die App meldet sich bei unserem Server und informiert uns über die Aufladung des Kontos. Dabei verwenden wir eine einfache SSL verschlüsselte RESTful API mit c2m (customer to machine) Autorisierung und Authentifizierung und senden den Topup-Befehl einfach selber. Denkste!! Diese Art von Aufladefunktion schreit nur nach Men-in-the-middle Attacken. Auch wenn es zunächst undenkbar scheint die API und auch noch den verschlüsselten HTTP-Request zu knacken, so ist auf dem Server dennoch nicht klar, ob die Zahlung wirklich verifiziert ist.

Verifizierung

Die Lösung dieses Problems ist die Antwortnachricht des Anbieters. Hier erhalten wir einen verschlüsselten String mit allen Informationen aus dem Kauf. Diese Nachricht senden wir aus der App einfach weiter an den Server. Der Server (selber Entwickler wie die App in diesem Fall wir) hat ebenfalls den Key zur Hand und ist damit in der Lage die Nachricht zu entschlüsseln und die Werte auszulesen. Die App sendet also die relevanten Nutzerdaten, die ID des gekauften Vouchers (Produkt 5 Euro bspw.: {“amout”: 5.00, “id”: “de.entwickler.voucher.five”}) und die Nachricht an unseren Server.

Der Server entschlüsselt die Nachricht mit dem Key und gleicht die enthaltenen Werte mit denen ab, welche die App zusätzlich mitgeliefert hat. Außerdem steht noch der Status der Transaktion in der Nachricht, so dass dort noch einmal klar sichergestellt werden kann, dass die Zahlung erfolgreich durchgeführt und nicht abgebrochen wurde. Erst jetzt ist klar, dass die Zahlung tatsächlich stattgefunden hat. Das Serverprogramm lädt dem Konto den verbuchten Betrag auf und bestätigt die Anfrage der App mit einem “Okay”. Die serverseitige Verifizierung ist damit abgeschlossen. So ist es ebenfalls möglich, In App-Käufe auch für Geldtransfer zu benutzen. Für Apple IAP https://gist.github.com/jamesstout/5073237 und Google IAB https://github.com/mitchobrian/google-play-in-app-billing-verification gibt es ein paar Beispiele für die serverseitige Verifizierung der Nachricht. Bei Google kann dies unmittelbar auf dem eigenen System durchgeführt werden. Für die Apple Nachrichten gibt es wiederum eine API zu finden unter https://sandbox.itunes.apple.com/verifyReceipt für die Prüfung des Kaufvorganges.

Fazit

Für die maximale User Experience kann es wünschenswert sein, zusätzlich zu den üblichen Zahlungsdienstleistern ebenfalls die hauseigenen Boardmittel von Apple und Google mit anzubieten. Die Implementierung ist dabei nicht üppiger als bei PSP1-APIs. Der Entwickler muss natürlich sein Developer-Konto um die Kaufoptionen für App-Kunden erweitern und die hohen Provisionen für Google und Apple in Kauf nehmen. Diese können unter Umständen den Business-Case zerstören. Üblicherweise nehmen beide im Durchschnitt 30% des Kaufbetrages für die Bereitstellung des Dienstes. Daher ist bei einem Produkt mit einer Marge darunter dieser Service mit Vorsicht zu genießen.

Dieser Artikel ist outdated - geschrieben im Jahr 2015

Die Halbwertszeit von Software

Michael Palmer — Tue, 29 Dec 2020 18:57:44 +0000

Software hat kein Verfallsdatum? Dem kann ich nicht zustimmen. Software fängt zwar nicht an zu riechen, schlecht wird sie aber dennoch. Dies kann man in vielen Artikel aus der Jahrtausendwende herauslesen. Das Chaos der doppel 0 führte damals zu einer falschen Panik. Aber auch diese sollte uns die Augen geöffnet haben.
Die Probleme alter Softwaresysteme finden sich in zwei Hauptkategorien. Die wesentliche dabei ist die Sicherheit des Systems angreifbar von aussen zu sein. Die zweite wäre der Performancefaktor. Dieser wird oftmals noch mehr vernachlässigt als der erste. Die Gründe liegen klar auf der Hand. Das System läuft seit Jahren. Tut genau was es soll und war damals in der Anschaffung auch noch sehr teuer. Also, zunächst kein Handlungsbedarf. Damit Punkt eins keinen Strich durch die Rechnung macht wird das System kurzerhand nach außen vollkommen abgeschottet. Never change a running System, Punkt. In vielen Hardwarenahen Systemumgebungen in der Industrie ist dieses Vorgehen sogar relativ unkritisch. In der Webwelt eher nicht. In den letzten Jahren sind zahlreiche Cloudplattformen aus dem Boden gestanzt worden. Viele über Jahre zu dem Entwicklt was sie heute anbieten. SaaS oder PaaS für fast jedes Einsatzgebiet. Diese Software muss zwingend auf dem aktuellen Sicherheitsstand sein. Wir verlassen uns auf sichere und hochperformante Services.

Kann man eine Formel erstellen wann Software sein Lebensende erreicht hat? Bislang komme ich nicht zu diesem Punkt. Es fällt schwer klare Aussagen zu treffen. Auf jeden Fall muss jemand unter die Haube schauen und den Motor inspizieren. Dabei fällt dem Programmierer oftmals die “veraltete” Architektur auf die Füsse. Sequentielle Skripte und viel verteilte Businesslogik machen die Analyse sehr teuer und aufwendig. Nun muss die erste Entscheidung getroffen werden. Was ist günstiger, eine Systemanalyse und ein Redesign, Neuaufsetzen der Software. Oder ist das System so komplex das die Logik zu extrahieren zeitlich das Budget schon sprengt und daher Wartung die günstigere Option ist. Nur wer kann jetzt in die Glaskugel schauen und sagen wie lange dauert die Wartung das System sicherer, stabiler und moderner zu machen. Und was genau muss gemacht werden? Hier kommen viele Fragen zusammen. Die Verantwortung der Entscheidung möchte wohl lieber keiner übernehmen.

...

Geschrieben im Jahr "2015" - wie ist der Stand heute?

Business-driven Development

Michael Palmer — Tue, 29 Dec 2020 18:45:47 +0000

Im Zuge der anstehenden Neuanstellungen bei uns im Betrieb und der damit verbundenen Vertragsgestaltungen, besonders in Bezug auf die neue Abteilungsform „DevOps“, habe ich mir einmal meinen Arbeitsvertrag aus dem Jahr 2010 angesehen. Darin stolperte ich über mein Einsatzgebiet und freute mich, dass es damals wie heute noch so treffend ist.

Im Wortlaut steht dort als eine von vielen Aufgaben: „Überarbeitung und ggf. Neukonzeption der bestehenden Systemarchitektur inkl. Schnittstellen und Modulen unter Aspekten der Wartbarkeit, Wiederverwendbarkeit, Sicherheit und Kosten-Nutzen-Verhältnis.“

Besonders der letzte Aspekt gefällt mir sehr gut: Kosten-Nutzen-Verhältnis. Was heißt das? Schlecht programmieren und schnell online gehen? Bestimmt nicht. Test-driven entwickeln, warten bis das System durch eine übergeordnete Prüfungskommission abgenommen und alle Sicherheitsstandards eingehalten sind? Eher auch nicht! Was also? Die Wahrheit liegt wohl dazwischen. Business-driven Development habe ich es vor Ewigkeiten getauft. Die Brücke zwischen schlimmen Hacking und schwergewichtigen Lasten- und Pflichtenheften. Wir sind ja agil!

Dem Wikipedia Artikel aus dem Jahr 2006 stimme ich allerdings nur bedingt zu. Dieser bezieht sich sehr stark darauf, dass der große Vorteil in der harten und direkten Verknüpfung der Geschäftslogik mit der zu erstellenden oder zu erweiternden Software liegt. Dies ist aber in meinen Augen kein neues Merkmal des Business-driven Development, sondern findet sich in vielen agilen Methoden wieder. Es charakterisiert viel mehr die Ansätze des Kanban und Scrum Prozesses, Projekte zu erstellen, zu planen und umzusetzen. Der Bezug zur Geschäftslogik wird also mehr auf der Projektplanungsebene gezogen. Auf der Softwareerstellungsebene muss dies dann in guten, wartbaren, nachhaltigen, sicheren und sauberen Programmcodes überführt werden. Genau an der Stelle scheiden sich die Geister. Clean-code Development ist für die meisten schon zum Standard geworden. Aber nur dieser Ansatz reicht bei weitem nicht aus. Die Strategie eines Teams, sich für eine Vorgehensweise zu entscheiden, ist essentiell für den Erfolg der Software und des Teams. Software muss nach der Erstellung unabhängig der Strategie wartbar bleiben.

Welcher der Ansätze für das Team am besten funktioniert, überlasse ich jedem selbst. Hier geht es darum, den Unterschied zu den, ich nenne sie mal klassischen Methoden, heraus zustellen. Im Gegenteil zu Test-driven Development, Behavior-driven Development, Design-driven Development, User-centered design oder einem der vielen anderen steht beim Business-driven Development die Anwendbarkeit im Vordergrund. Das bedeutet, neue Features sollen durch eingerichtete Test-Stages in der Produktion sofort mit dem Kunden abgestimmt werden können. Die Umsetzung muss aus bestehenden und etablierten Komponenten bestehen. Neue Technologien werden als early alpha Prototypen sofort auf Test- oder Produktions-Stages implementiert und in Abstimmung mit dem Steakholder ausprobiert. Ist ein Feature in diesem Zyklus noch interessant so wird die Implementierung reverse refactored. Das bedeutet, bis zu diesem Zeitpunkt gab es noch keinerlei Designentscheidungen. Diese werden jetzt getroffen und mit der neuen Technologie verbandelt oder in das bestehende System integriert. Im Unterschied zum Live-Hacking darf der Prototyp nicht in der Form im System bestehen bleiben. Nach der Implementierung muss die Zeit investiert werden, die wesentlichen Bestandteile neuer Software nach zu liefern. Diese sind Readme, Integrationstest und Changelog. Damit ist gewährleistet, dass andere Entwickler schnell den Einstieg in die Implementierung finden. Anhand des Changelogs werden Patches sowie Features schnell identifiziert. Die Readme (diese kann ein Wiki oder eine Textdatei sein) gibt den Überblick (bspw. Linksammlung) zur Technologie und der Designentscheidung für die Implementierung. Der Test gehört in das Continuous Integration. Denn ganz klar, ohne dieses Sicherheitsnetz für jedes noch so kleine Feature ist diese Art von Vorgehen in der Softwareentwicklung lebensgefährlich und fahrlässig.

Ich behaupte also, Business-driven Development vereint die vielen Vorteile verschiedener Entwicklertypen (8 different types of programmers http://david.elbe.me/programming/2015/05/25/different-types-of-programmers.html) in dem sie schnell Funktionen anbieten können, ohne große Projekte akquirieren zu müssen. Weniger Pre-Sales, was dazu führt, dass diese Mittel später in den Feinschliff der Software gesteckt werden können. Außerdem können somit Probleme, welche üblicherweise während der Softwareentwicklung auftreten, durch schnelles ausprobieren (trial-and-error Prinzip) kostengünstig untersucht werden. Die schwerwiegenden Showstopper, welche oftmals große Softwareprojekte zum scheitern zwingen, werden frühzeitig erkannt. Der so oft auftretende teure Ausstieg nach einer langen Entwicklungsphase bleibt aus. Ein wesentlicher Punkt, warum Softwareprojekte scheitern, wird ausgehebelt. Hürden können nicht genommen werden und sorgen nach endloser Arbeit dazu, dass ein Produkt nicht den Anforderungen entspricht und daher nicht den gewünschten Kundenerfolg einbringt. Damit wird viel Geld und Zeit verbrannt. Business-driven Development löst dieses Problem. Um meine These zu untermauern und einen deutschsprachigen Wikiartikel dazu zu verfassen, benötige ich allerdings mehr Anhänger meiner Theorie.

Geschrieben im Jahr "2015"

Und das Design?

Michael Palmer — Tue, 29 Dec 2020 18:40:35 +0000

In der agilen Entwicklung drehen sich die Themen vor sowie im Umsetzungsverlauf überwiegend um Funktionen. Usability und Design lassen sich nur im Zusammenspiel mit diesen Funktionen verkaufen.

Ein Bericht aus der Praxis
Vor Projektanfang steht die Idee. Diese ist mehr als großartig und damit vielversprechend. Sie hat das Potential eine große Nutzerzahl ansprechen zu können. Doch wie jede Idee, ist sie nur eine Idee. Sie hat noch keinen Rumpf und damit weder Hand noch Fuß. In unserer Branche generieren schlaue Produktmanager ständig Ideen dieser Art. Gänzlich unklar ist, inwieweit diese Ideen sich umsetzen lassen und Bestand auf dem Markt haben werden. Damit diese Ideen dennoch alle möglichst schnell und kosten(los)günstig umgesetzt werden, bedienen wir Projektmanager uns der Softwareentwicklung zugeschriebenen Begriffe wie agil. Damit meinen wir jedoch schnell und unkompliziert. Schlecht ist diese Zweckentfremdung jedoch keines Falls. Sie hilft den leitenden Architekten und Teamleitern ihre Methoden mit einfachen marketingtechnischen Mitteln an den Mann, hier den Geschäftsführer, zubringen. Dass aber aufgrund der gänzlich unterschiedlichen Auffassungen des Wortes agil viele Dinge schief gehen, sieht man in der Praxis. Wir reden über die Umsetzung einer Idee. Sofern sich bis Dato keiner die Mühe gemacht hat auch nur eine Zeile zu Papier zu bringen, ist diese Idee am Tag sieben noch genau so eine Idee wie am ersten Tag. Gesprochenes Wort kann jedoch nicht unterschrieben werden. Damit haben wir auch keinen Projektauftrag. Wir starten also, auch wenn wir agil arbeiten, immer erst dann, wenn wir eine Zieldefinition aufgeschrieben haben. Diese muss kein Roman sein. Aber zumindest ist dann klar, dass wir eine Schaukel zwischen zwei Bäumen mit einem Brett als Sitzgelegenheit und keinen Gummireifen, angebracht an einem Ast, haben wollen. Mit der Zieldefinition kommen die Userstories. Diese zu formulieren, fällt den meisten Produktmanagern in ihrer Rolle als Productowner nicht mehr schwer, so dass sie wie Twitter-Kurznachrichten nur so ins Backlog purzeln. Hier gilt der Grundsatz, lieber zu viele als unklare oder gar fehlende Anforderungen. Damit sind das Projekt und seine Anforderungen definiert. Das Ziel ist im groben klar und durch die Priorisierungen wissen alle, was zuerst gemacht wird. So wird sichergestellt, dass der Kunde einen möglichst frühen und dabei hohen Nutzen eines ersten Releases hat. Unabhängig von der dennoch fehlenden Umsetzungsdauer in exakten Minuten ist der Steakholder und sein in die Verantwortung gezogener Productowner bis hier hin sehr zufrieden. Jetzt liegt es nur noch an den Entwicklern. Diese schrauben und drehen was das Zeug hält und liefern an der einen oder anderen Ecke sogar etwas mehr oder bessere Software als angefordert. Dann kommt der Tag X, an dem der Productowner in der Review einen ersten Prototypen der Software visuell präsentiert bekommt. Hier ist oftmals die Überraschung groß. „Hübsch ist das Formular nicht gerade!“. Die Reaktion der Entwickler überrascht allerdings kaum jemanden, denn „hübsch war kein Akzeptanzkriterium!“. An dieser Stelle wird das Design zum Thema.

Sicherheit, Qualität und Aussehen
In der schnelllebigen Welt von Mini-Applikationen ist es nicht verwunderlich, dass das Design zurücktreten muss. Neue Funktionen müssen möglichst schnell und sicher bereitgestellt werden. Dabei ist der Punkt Sicherheit heute viel relevanter als noch vor wenigen Jahren. Kaum ein Kriterium ist so kritisch wie offene Tore bei Backend-Anwendungen besonders in Bezug auf APIs. Im Grunde heißt dies, wir legen heute unser Augenmerk auf Dinge, die uns vor wenigen Jahren extrem auf die Füße gefallen sind. Sei es die Sicherheitslücke durch XSS, SQL-Injection oder CSRF beziehungsweise das Brechen von Codemetriken und die damit entstehenden technischen Schulden. Jetzt haben wir Software auf gutem Niveau. Jedoch bleibt die große Anzahl an Nutzern aus, da die Software nicht ansprechend designed oder nicht zu bedienen ist. Dank der modernen Frameworks sind grundlegende Einstellungen an dem GUI bereits vor der ersten Zeile Code vorgenommen und sollten in vielen Fällen auch aufgrund der Wiedererkennbarkeit nicht angepasst werden. Nehmen wir den Style Guide von Apple für das iPhone oder den von Microsoft für das Windows Phone. Hier sind die Parameter ganz klar definiert und Frameworks zum Erstellen solcher Applikationen lassen dem Entwickler auch wenig Spielraum sich davon zu entfernen. Das Einhalten der Richtlinien macht die Anwendung aber keinesfalls bedienbar noch „hübsch“. Warum also kommt das Aussehen erst an dritter Stelle? Software wird doch in den allermeisten Fällen nicht für einen selber, sondern für einen Dritten geschrieben. Dieser soll sich direkt mit dem Programm wohlfühlen und es aufgrund schlechter Anordnung, grausamer Farben oder überladenen Bildschirmen nicht abstoßen!

Zeit ist Geld
In jedem Planungsteam gibt es einen Spielverderber. Dieser hört sich alle Ideen aufmerksam an und lässt das Team alle Anforderungen ausgiebig zusammentragen. Zum Schluss kommt er dann mit dem stumpfen Messer und zerreißt all die ordentlich aufeinander aufbauenden Teilpunkte zu einem Salat von Anforderungen, welche eine Software hinterher erfüllen muss. In dieser Phase spielt fast ausschließlich das Geld eine Rolle. Projektbudgets sind immer knapp und zunächst brauchen wir Funktionen, um den Kunden abholen zu können. Damit ist klar, warum Aussehen plötzlich weit in die Ferne gerät. Wir alle wissen, dass gerade im Punkt Layout viel Zeit investiert werden kann, um alle Kriterien der Nutzbarkeit und Ordnung auf dem Bildschirm zu erfüllen. Diese Zeit kostet Geld. Und diese Investition bringt dem Steakholder zunächst kein Return-of-Investment. So denkt er zumindest, aber falsch gedacht. Eine ausgiebig eingeplante Designphase in einem Projekt scheint erst mal nicht notwendig. Eine Verabschiedung von Templates für wiederkehrende Sichten allerdings schon. In agilen Projekten wird der Kunde zum Tester. Dieser Nutzer sollte in die Gestaltung des Designs einbezogen werden. In der Prototypphase kann mit dem Benutzer zusammen die logische Aufbereitung von Bildschirmen erarbeitet werden. Diese Vorgehensweise erspart nicht nur Zeit, sondern verhindert auch die sich wiederholenden Arbeitsprozesse in der Abnahme eines vollständig erstellten Designkonzeptes.

Freie Hand
Während der Erstellung der First-Alpha-Version kommen auf den Entwickler aufgrund neuer Produktideen auch meist neue technologische Hürden zu. Mit diesem Hintergrund begrüßen viele den lockeren Umgang mit dem Layout. Wichtig für den Architekten oder das selbst kontrollierende Team ist, dass die Entwicklung nicht in eine statische Einbahnstraße getrieben wird. Dazu gibt es Technologien mit denen Layoutanpassungen programmiertechnisch jeder Zeit anpassbar sind. In der Webwelt zählen die Cascading Style Sheets (CSS) in Verbund mit View-Templates zu den angesagtesten Methoden. Das Zusammenspiel erlaubt es, Layoutvorlagen für verschiedene Sichten zu erstellen, welche im Programmablauf ständig recycelt werden können. Mit Hilfe der Klassen in CSS lassen sich zunächst die Elemente sinnvoll auf dem Bildschirm platzieren, ohne auf ihre Erscheinung Rücksicht nehmen zu müssen. Im Nachgang fällt es den Designern sowie den Productownern um einiges leichter, die detaillierten Layoutentscheidungen anhand der klickbaren GUIs zu treffen. Hierbei geht es schlussendlich um die genaue Positionierung von Fenstern oder die Fenstergröße für bestimmte Inhalte. Besonders bei Fenstern mit dynamischem Inhalt lässt sich vorab nur schwer bestimmen, welche Größe notwendig für den Inhalt aber minimal für den stilistischen Charme ist. In der Praxis zeigt sich gerade bei diesen Entscheidungen der Teufel im Detail. Viele Ehrenrunden muss der Designer drehen bis der Productowner zufrieden ist und schlussendlich muss das Fenster beispielsweise doch die ganze Breite des Bildschirmes einnehmen.

Fazit
Während eines Projektes ist der Entwickler am nächsten an der Software und hat damit auch die innovativsten Ideen zur erstmaligen Gestaltung von Bildschirmen. Sofern die richtigen technologischen Entscheidungen getroffen wurden, kann das Layout im Nachgang solange angepasst werden bis die Software im Uhrwerk und im Ziffernblatt perfekt abgestimmt ist. Ein vorab erstelltes Design hingegen ist statisch und lässt sich nur schwerfällig an veränderte Softwareeigenschaften angleichen. Halten wir fest: so genannte Mockups retten uns auch nicht vor der Katastrophe. Der ständige Kontakt zum Productowner und die Einhaltung von Style Guides hingegen vermeiden Überraschungen und bilden das Fundament für nachhaltige Softwareentwicklung.

Geschrieben im Jahr 2012