≡ Menu

Foto: race von telmo32 (Lizenz: CC-BY-ND)

Worauf musst du achten, wenn du als Softwareentwickler durchstartest und nicht mehr einzuholen bist?

Wenn du dabei bist, die Software so grundlegend umzugestalten, dass kein Stein auf dem anderen bleibt?

Wenn du plötzlich und ungewollt dem ausgesetzt bist, was allgemein als Veränderungsmanagement bezeichnet wird?

Wenn du dir mindestens einmal in der Woche vornimmst, das Pinguin-Prinzip noch einmal zu lesen?

Druck von außen

In unserer konkreten Situation haben wir Entwickler drei „Kunden“:

  1. Consultants/Projektentwickler, die mit dem Produkt Projekte umsetzen wollen.
  2. Verkäufer, die den Kunden überzeugen wollen, dass das Produkt seine Anforderungen schon von Haus aus optimal abdeckt oder mit geringem Aufwand abdecken wird.
  3. Endkunden, die das Projekt bezahlen und einsehen sollten, dass ihre Wünsche auf die zur Verfügung stehende Funktionalität abgebildet werden müssen.

Dabei haben wir mit der ersten viel, mit der zweiten weniger und mit der dritten Gruppe so gut wie keinen direkten Kontakt. Entsprechend verteilt sind die Anfragen, die uns erreichen.

Hier sind meine Erkenntnisse aus den typischen Situationen, die sich daraus ergeben:

Zunächst einmal: Genieß den Augenblick

Produktentwicklung macht großen Spaß — nur selten hat man die Möglichkeit, sich praktisch fortwährend mit neuen Technologien beschäftigen.

Ausprobieren, evaluieren, umsetzen. So manches auf der grünen Wiese anfangen. Der Traum all jener Entwickler, die in den technischen Vorgaben von Kunden gefangen sind und zum Teil mit uralter Technik moderne Anforderungen umzusetzen versuchen. (Haltet durch, Jungs!)

Diese Arbeitsweise ist purer Luxus. Das sollte man unbedingt zu schätzen wissen.

Halte den Wissens-Vorsprung klein

Erkläre den anderen, warum Änderungen notwendig sind. Welchen Nutzen sie bringen. Stell dich darauf ein, das immer wieder erklären zu müssen.

Diese Kommunikation nach außen ist eine echte Gratwanderung. In technische Details zu verfallen kann genauso ins Auge gehen wie immer nur zu behaupten, es werde alles gut.

Achte darauf, das große Ganze dahinter richtig zu verkaufen: Um die gewünschte Adaption zu erwirken, müssen manche Ideen als radikaler Bruch vermarktet werden — auch wenn man im ersten Moment meint, dass kleine Änderungen besser verdaut werden können.

Teile deine Werkzeuge, Lösungen Erkenntnisse und Arbeitsweisen mit den anderen und schotte dich nicht ab. Nimm dir die Zeit, zwischendurch den aktuellen Stand oder kleine Nebenprodukte zu präsentieren.

Bekämpf die Gerüchte von Anfang an

Wer nicht in die Entwicklung involviert ist, neigt dazu, Annahmen auf Basis seiner Kenntnisse zu treffen.

So entstehen Gerüchte: Stimmt es, dass Feature X abgekündigt wird? Das wäre alles viel schneller gegangen, wenn… Und überhaupt — warum kümmert ihr euch nicht erstmal um die wichtigen Dinge?

Es ist unglaublich schwierig, Entscheidungen später zu rechtfertigen als andere früh darauf vorzubereiten und mitzunehmen. Wehe, wenn dann noch eine Sache nicht läuft wie geschmiert!

Hinterher ist bekanntlich, wenn man’s vorher gewusst hat.

Erschwerend kommt hinzu, dass man sich als Produktentwickler viel zu schnell an den Zustand gewöhnt hat, dass viele Dinge kaputt sind, deaktiviert oder gelöscht werden.

Wenn du das falsch kommunizierst, ist das guter Nährboden für weitere Gerüchte.

Sieh dich auch mal um

Auch wenn Umsetzung und Kommunikation nach außen einen Großteil des Tagesgeschäfts ausmachen — vergiss nicht, dass Feedback aus den Projekten überlebenswichtig für ein gutes Produkt ist.

Halt also die Ohren offen. Welche Lösungen sind im Einsatz? Was muss verbessert werden? Was wird gebraucht? Und viel wichtiger: Was kann wegfallen?

Gerade dieser letzte Punkt ist selten offensichtlich und wird oft nur zwischen den Zeilen erwähnt. Features zu streichen erfordert Mut auf der einen und Einsicht auf der anderen Seite.

Finde dein Tempo

Und zwischen all dem ist Software-Wartung vielleicht noch ein Thema.

Einfach mal einen ganzen Tag nur den Blick nach vorne richten? Vergiss es. Kontextwechsel sind an der Tagesordnung, wenn du dich auch noch um die aktuelle Version des Produkts kümmern, Fragen beantworten und Probleme untersuchen musst.

Daher ist es ratsam, sein eigenes Tempo zu finden, Anfragen zurückzustellen und stapelweise abzuarbeiten. Finde heraus, was für dich am besten passt, ohne die anderen vor den Kopf zu stoßen.

Kommunikation ist das A und O bei großen Veränderungen. Nimm die anderen mit.

Sonst haben sie schon keine Lust mehr, bevor ihr überhaupt fertig werdet.

{ 7 comments }

Foto: Gimme a V von hjhipster (Lizenz: CC-BY-NC)

5 lesenswerte Artikel zu unterschiedlichen Themen aus der Softwarebranche:

Softwarevertrieb

Kaum zu glauben, aber wahr — in meinen drei Jahren als Vollzeit-Entwickler habe ich bisher weniger über den Vertrieb von Unternehmenssoftware gelernt als durch diese vierteilige Serie:

The very most basic things your company needs to know about sales

Merkmale erfolgreicher IT-Ingenieure

Du weißt schnell, wenn du einen vor dir hast. Aber was genau macht einen erfolgreichen Software-Ingenieur aus?

Top Three Traits of Successful Engineers

Interfacedesign

„Sollen wir den Button unten oder oben platzieren?“ — „Mach eine Option draus!“ Anpassbarkeit von Elementen ist nicht immer die beste Wahl:

The Pitfall of Customizability in UI Design

Flamewars

Wenn es um Tools geht, sind in der Softwarebranche die Fronten schnell verhärtet — Linux gegen Mac gegen Windows, die ewige Editor-Diskussion, oder auch das Thema Versionsverwaltung. Um dem wiederkehrenden „Murmeltiertag“ ein Ende zu setzen, hat Benjamin Pollack einen Vorschlag:

Make Love, Not Flamewars

Schätzungen

Schätzungen sind ein Problemkind unserer Branche und mit ein Grund, warum agile Methoden wie Scrum so schnell populär geworden sind. Warum es nicht gut ist, Schätzungen zu viel Bedeutung zu geben:

Estimates are overrated

{ 2 comments }
Charles Darwin im Alter von 71 Jahren (Lizenz: gemeinfrei)

Charles Darwin im Alter von 71 Jahren (Lizenz: gemeinfrei)

„Es ist wie einen Mord zu gestehen“, schrieb Darwin in einem Brief, als er langsam zu der Überzeugung kam: Arten sind nicht unveränderlich.

Das war 1844, eineinhalb Jahrzehnte vor der Veröffentlichung seines Hauptwerks Die Entstehung der Arten. Er war dabei, mit seinen Beiträgen zur Evolutionstheorie alles auf den Kopf zu stellen.

Heute erscheint die These weit weniger radikal als noch bei der Veröffentlichung: Arten verändern sich, um sich besser an die Umwelt anzupassen.

Dabei bleiben vorteilhafte Variationen erhalten.

Evolution in der Softwareentwicklung

Genau diese Grundannahmen der Evolution machen sich Softwareentwickler heute zunutze.

Bei der evolutionären Entwicklung wird zunächst nur eine Anwendung mit den Grundfunktionalitäten bereitgestellt. Dann wird nach und nach erweitert — entsprechend des Feedbacks vom Kunden.

Natürlich ist dabei der Entwickler die treibende Kraft, im Gegensatz zu Darwins natürlicher Selektion. Software entwickelt sich nicht von allein weiter.

Deshalb ist auch das Prinzip des Gradualismus, also Änderungen in vielen Zwischenschritten, nicht gegeben. Es ist aber Voraussetzung für eine erfolgreiche Evolution des Systems und sollte Ziel der Weiterentwicklung sein.

Paradebeispiel Open Source Software

Open Source Software wird ja praktisch nur evolutionär entwickelt.

Linus Torvalds hat sich vor 20 Jahren nicht hingesetzt und geplant, Linux in einem guten Jahrzehnt auf den Großteil der Server zu bringen und es zu einer wirtschaftlichen Größe zu etablieren.

Typischerweise entstehen ja Open-Source-Projekte so, dass jemand ein ganz spezielles Problem für sich selbst löst. Mit ein bisschen Glück findet man Mitstreiter, die neue Funktionalität dazu- oder vorhandene entsprechend ihrer eigenen Wünsche umbauen.

Die Software evolviert über die Zeit.

Gern wird auch mal zu drastischen Mitteln gegriffen, um ein Projekt voranzutreiben. Aus der durchaus lesenswerten Erklärung, warum einige Entwickler aus der Community um das Projektmanagement-Tool Redmine es für sinnvoll erachteten, das ChiliProject abzuspalten:

However, in the view of some of Redmine’s leading developers, the maintenance and evolution of Redmine has not been as predictable and responsive as its developer community is capable of […] A group of developers from the Redmine community has therefore concluded that the only way to ensure continued, sustained and stable development of our favorite project management solution is to fork it.

In Darwins Augen ist hier also eine neue Art entstanden.

Flexibilität und Wartbarkeit sichern: Evolution statt Sackgasse

Um evolutionäre Entwicklung zu fördern und Software später an veränderte Bedingungen anpassen zu können, müssen Programme flexibel gehalten werden. Sonst drohen irgendwann teure Neuentwicklungen.

Das schafft man nur, wenn regelmäßig aufgeräumt und dem Verfall rechtzeitig vorgebeugt wird.

Dann ist man auch in der Lage, agil zu entwickeln.

Vorbei die Zeit, in der Softwareprodukte in jahrelangen Prozessen am Kunden vorbei spezifiziert und umgesetzt wurden. Die Vorstellung, heute schon wissen zu können, welche Detailfunktion der Kunde in ein paar Jahren braucht, muss einem da zwangsläufig wie Schöpfungsbiologie vorkommen.

Zusammenfassung

Darwin zögerte damals, die Theorie zu veröffentlichen. Seine ursprüngliche Auffassung war die Unveränderlichkeit der Arten gewesen, aber seine und die Recherchen anderer widerlegten die These. Und er war sich der Tragweite seiner Entdeckungen bewusst.

Sein Hauptwerk schloss er mit dem Satz:

Es ist wahrlich etwas Erhabenes um die Auffassung, [dass] aus einem so schlichten Anfang eine unendliche Zahl der schönsten und wunderbarsten Formen entstand und noch weiter entsteht.

Diese Feststellung lässt sich so sogar auf Software übertragen.

Hast du schon Erfahrung mit evolutionärer Entwicklung gesammelt? Sag’s uns in den Kommentaren!

{ 4 comments }

Eindrücke von der EuRuKo 2011

test

Ihr kennt mich ja: Ich habe beruflich viel mit der Programmiersprache Ruby zu tun und empfehle sie sogar Anfängern.

An diesem Wochenende fand die EuRuKo in Berlin statt. Diese jährliche Konferenz wird von der Community organisiert und fand davor in Krakau statt.

Die Konferenz ist durch die Art der Organisation eher informell, was die ganze Sache nur sympatisch macht. In der Berliner Ruby-Szene kennt man sich — und das schließt die Sponsoren ein. Trotzdem zieht die Veranstaltung Besucher nicht nur aus Europa, sondern der ganzen Welt an.

Stilecht wurde das Kino International als Veranstaltungsort ausgewählt — in meinen Augen ein echter Geniestreich des Orga-Teams! Es finden keine Veranstaltung parallel statt (was ich nur begrüße), und daher ist ein Kino ideal für die EuRuKo.

This slide intentionally left blank

Highlights

Die Highlights der Konferenz in Kürze:

  • Keynote — Yukihiro “Matz” Matsumoto

    Es ist schon großes Glück, auf einer solchen Konferenz den Erfinder der Sprache als Redner dabei zu haben. Matz hat hauptsächlich über die Rite VM, eine virtuelle Maschine für Ruby, die für eingebettete Systeme geeignet sein soll, vorgestellt.

  • Ruby helps us make movies — Julik Tarkhanov

    Ein schöner Vortrag, um über den Tellerrand zu schauen: Julik hat einen schönen Einblick in den Alltag der Post-Produktion von Filmen (Kino und Werbung) gegeben. Ruby wird also noch an anderen Stellen als im Web-Umfeld eingesetzt.

  • The Revenge of method_missing()Paolo Perrotta

    Was machst du, wenn du ein Buch geschrieben hast, aus dem die Community die falschen Schlüsse zieht? Ganz einfach: Du stellst das in einem Vortrag richtig. Aber Paolo hat nicht nur den Rahmen für seinen Vortrag gut gewählt. Er brachte es auch noch gut rüber. Einer der unterhaltsamsten Vorträge:

    The Revenge of method_missing()

  • Keynote — Paul Campell

    Wer ist eigentlich Paul Campell? Das haben sich einige gefragt. Er hat Ketchup mit entwickelt. Und ansonsten sei er nur ein ganz normaler Kerl, der versucht durch’s Leben zu kommen. Die Einblicke in die Vorbereitung seiner Keynote hätte er uns ersparen sollen, aber die Quintessenz „lerne Dinge, die für dich ungewohnt sind und erweitere so deinen Horizont“ gefällt mir.

  • Tales of the Big White Cloud — Pat Allan

    Pat Allan kenne ich, seit er auf der Ruby User Group mal Thinking Sphinx vorgestellt hat. Dieser Vortrag über seine Odyssee in der Cloud war schon fast eine richtig gute Lesung mit den besten Folien der Konferenz.

  • Getting Hands On with Adhearsion — Ben Klang und Ben Langfeld

    Noch eine Horizont-Erweiterung, wofür Ruby verwendet werden kann: Telefonie. Die beiden haben in einer erfrischend unkonventionellen Art und Weise eine App für Telefonkonferenzen live demonstriert. Und das nicht in der typischen Kombination aus Redegewandtem (kennt keine technischen Details) und Entwickler (kriegt keinen fehlerfreien Satz raus).

Nach der Konferenz haben offensichtlich die Teilnehmer noch „Ruby, Ruby, Ruby“ gesungen und Fronx hat’s aufgenommen. Danke dafür:

ruby, ruby, ruby, ruby by fronx

Update: Nico Hagenburger, der Konferenz-Website und T-Shirts entworfen hat, stellt im Nachhinein die 3 Typen von EuRuKo T-Shirts vor.

Abschluss

Die Chancen, dass die EuRuKo nächstes Jahr in Amsterdam stattfindet, stehen gut. Hab ich zumindest gehört.

Die letzten beiden Vorträge von Mateusz Drożdżyński und José Valim habe ich leider verpasst, weil ich früher los bin. Kannst du etwas dazu sagen?

Und wie war eigentlich dein Eindruck von der Konferenz?

{ 1 comment }
Foto: For big party

Foto: Shack Party von davef3138 (Lizenz: CC-BY-SA)

Wäre es nicht abwegig, zu zweit in einem Riesen-Haus mit 10 Zimmern zu wohnen, nur um ab und zu eine große Party zu feiern?

Da wäre es doch viel besser, bei Bedarf einfach die freien Kapazitäten in den umliegenden Wohnungen nutzen zu können.

Nur — machen das die Nachbarn mit?

In der IT sieht das anders aus: Hier können freie Kapazitäten viel flexibler genutzt werde, indem sie über ein Netzwerk bereitgestellt und nach Verbrauch abgerechnet werden.

Das ist Cloud Computing.

Der Vorteil davon liegt auf der Hand: Man kann flexibler auf geplante und ungeplante Ereignisse reagieren. Etwa wenn das Weihnachtsgeschäft bei einem großen Online-Shop ansteht. Oder wenn eine Aschewolke Tausende hilfesuchende Flugreisende plötzlich auf die Website treibt. Eine spontane Party sozusagen.

Für beide Fälle kann man aus finanziellen Gründen unmöglich das ganze Jahr Überkapazitäten vorhalten. Die Idee des Cloud Computing ist zwar nicht neu, kommt jetzt aber langsam in Fahrt und wird in der Branche immer stärker beworben.

Ist das nicht nur ein vorübergehender Trend?

Das glaube ich nicht, und zwar aus zweierlei Gründen.

Zum einen macht Cloud Computing wirtschaftlich Sinn. Das zeigt allein schon die Tatsache, dass die Cloud von Amazon aus der Notwendigkeit entstanden ist, im eigenen Shop mit Lastspitzen umgehen zu können. Natürlich lässt sich diese Rechnung nicht ohne Weiteres auf andere Unternehmen oder Privatanwender übertragen.

Die Geschichte und der Erfolg hinter Amazons Cloud unterstreicht aber, dass es sich nicht nur um eine Erfindung cleverer Marketing-Leute handelt.

Zum anderen stellen die technischen Konzepte durchweg Wert für den Kunden dar — sei es durch Flexibilisierung, schnellere Bereitstellung oder höhere Ausfallsicherheit und Verfügbarkeit.

Deshalb ist Cloud Computing nicht als vorübergehender Trend zu sehen.

Das ist doch nur für Unternehmen relevant, oder?

Klar — wenn man als Endanwender auf diese Vorteile verzichten möchte:

  • Kostenvorteile, die an mich weitergegeben werden
  • Robuste Dienste
  • Flexible Nutzung ohne willkürliche Obergrenzen und mit fairem Bezahlmodell (nach „Verbrauch“)
  • Zugriff auf (journalistische) Informationen, die sonst gar nicht verfügbar gewesen wären
  • Zugriff auf Systeme, deren Einrichtung oder Betrieb Spezialwissen oder einen erheblichen Zeitaufwand erfordern

Alter Wein in neuen Schläuchen?

Wer sagt, dass Cloud Computing „im Prinzip nichts Neues“ ist, lässt vor allem technische Aspekte außer Acht.

Technisch muss man umdenken, was in vielen Fällen zum richtigen Ansatz führt: Der Kaputt-Zustand wird langsam als normal angesehen, und Anwendungen werden um dieses Szenario herum entworfen. (Mal ehrlich: die allgemeine Wahrnehmung von Computern im Alltag ist doch eher, dass ihr Funktionieren reiner Zufall ist, oder?)

Das fängt schon damit an, dass die Einrichtung von Servern automatisiert wird. Vorbei die Tage, dass der eine einmal eingerichtete Server unter keinen Umständen mehr angefasst werden darf — wer weiß, was dann alles nicht mehr funktioniert? Zudem dokumentiert die Automatisierung, wie man zum aktuellen Stand überhaupt gekommen ist. Das ist den automatisierten Tests durchaus ähnlich.

Außerdem wenden Anbieter einige Zeit auf, um Systeme immun gegen (kurzzeitige) Defekte einzelner Bestandteile und damit robuster zu machen.

Aus technischer Sicht fühlt sich Cloud Computing vielfach richtig an, vor allem beim Betrieb. Man kann sich nicht vorstellen, die Anwendung mal anders betrieben zu haben.

Und das merkt man (hoffentlich) auch bei der Benutzung.

Löst Cloud Computing nun alle Probleme?

Zunächst mal löst Cloud Computing überhaupt keine Probleme. Daher sollte man auch nicht sofort begeistert sein, nur weil ein Dienst mit dem Hinweis „in der Cloud“ beworben wird. Hier stellt sich eher die Frage nach dem Nutzen: Unternehmen sollten glaubhaft machen können, warum sie Cloud Computing einsetzen und welcher Nutzen dabei für den Kunden besteht.

Außerdem sollte man sich gerade als Unternehmen immer wieder vor Augen halten, wie groß beim Cloud Computing die Abhängigkeit vom Anbieter werden kann: Amazon hat gerade eindrucksvoll bewiesen, dass auch ihre Cloud ausfallen kann.

Führt das nicht zu Kontrollverlust und Datenschutz-GAU?

In Deutschland wird der Datenschutz als hohes Gut angesehen, was durchaus als Standortnachteil gesehen wird. Hierzulande bringt Cloud Computing vor allem Datenschützer und Skeptiker auf den Plan.

Häufig ist dann die Rede von Kontrollverlust. Man wisse ja als Anwender beim Cloud Computing nicht mehr, wo die Daten gespeichert würden.

Das hat aber mit Cloud Computing nur bedingt zu tun, schließlich ist es ja nur ein technisches Konstrukt, um die Skalierung von Anwendungen zu erleichtern. Otto Normalverbraucher weiß als Anwender von Online-Anwendungen (ob nun cloud-basiert oder nicht) sowieso wenig darüber, auf welchen Servern Daten gespeichert werden.

Ausblick und Fazit

Cloud Computing als Marketing-Begriff wird über kurz oder lang wieder verschwinden, während die Technik im Hintergrund bestehen bleibt.

Die Erwartungen an die Verfügbarkeit von Anwendungen werden sich weiter erhöhen. Richtig eingesetzt birgt Cloud Computing hier durchaus Wettbewerbsvorteile.

Und Nutzer werden sich im Zweifel auf die Dienste konzentrieren, die auch mal ein paar mehr Partygäste aushalten.

{ 3 comments }

Shopping in Soho

Unseren letzten vollen Tag in New York ließen wir ganz in Ruhe angehen. Langsam aufstehen, gemütlich frühstücken und dann ab nach Soho und Nolita zum Shoppen. Und wir wurden prompt fündig (zum Glück ist der Rückflug schon bezahlt)!

Am frühen Nachmittag legten wir eine kurze Pause im Hotel ein, bevor wir noch einmal loszogen, um dem einzigen Stadtteil Manhattans, den wir uns noch nicht angeschaut hatten, einen Besuch abzustatten – Harlem. Ein interessanter Teil der Stadt, der nicht so viele Sehenswürdigkeiten zu bieten hat, aber in dem wir ganz schön auffielen!

Wir drehten eine Runde und nahmen wieder die Metro nach Midtown. Dort erledigten wir noch einige Einkäufe, bevor im Hotel das Kofferpacken anstand. Schade, dass unser schöner Urlaub nun fast vorbei ist…

{ 2 comments }

Kulturprogramm

Eigentlich wollten wir heute Fahrräder ausleihen und damit den Central Park näher erkunden. Doch das Wetter machte uns prompt einen Strich durch die Rechnung. Kaum traten wir aus dem Hotel, blitzte und donnerte es. Und dann fing es an zu schütten!

Also Plan B: das American Museum of Natural History. Die Subway-Station konnte man nicht verpassen – es stiegen gefühlt alle Erwachsenen mit Kindern aus. Der Ticketkauf und die Orientierung in dem großen Gebäude dauerten ein bisschen, aber dann ging’s los.

Und mal wieder müssen wir sagen: die Amerikaner haben es einfach raus, ein Museum für alle Altersgruppen ansprechend zu gestalten! Toll, wie hier die Tiere lebensgroß und in ihrer natürlichen Umgebung gezeigt werden. Und das Ganze mit wahnsinnig viel Liebe zum Detail (von den Pflanzen, Hufabdrücken bis zu den entsprechenden Hinterlassenschaften der Tiere). Wissenschaftler, Maler, Bildhauer etc. waren auf Exkursionen in den jeweiligen Regionen, um die Exponate so lebensecht wie möglich darzustellen. Beeindruckend!

Und so verbrachten wir den halben Tag im Museum. Zusätzlich zur permanenten Ausstellung schauten wir uns noch die Sondershow “The world’s largest dinosaur” an. Hier wurde in sehr anschaulicher Weise alles über diese gigantischen Sauropoden erklärt.

Nicht allzu spät ging es zurück ins Hotel – schließlich wollten wir noch zur Dinner Cruise. Also machten wir uns richtig schick (Schlips und Kragen) und nahmen – NYC-Style – ein Taxi zum Pier 81. Das Einschiffen war gar kein Problem und schon hatten wir einen Drink (naja, eher nur ich) und ein Amuse Bouche (Wikipedia: “appetitanregendes, kleines und somit mundgerechtes Häppchen”) vor uns.

Bald wurde dann auch abgelegt und wir waren fasziniert von der schönen Aussicht! Sogar die Sonne war wieder rausgekommen, um uns einen würdigen Untergang zu zeigen. Und dann funkelten die Lichter der Stadt!

20110428-232408.jpg

Highlight war ganz klar die erleuchtete Lady Liberty aus der Nähe, die Skyline von NYC und dazu romantische Musik auf dem Deck des Schiffs! Es gibt nichts Schöneres für eine Hochzeitsreise!

Insgesamt war die Fahrt ein tolles Erlebnis: leckeres Essen, exzellenter Service, super Stimmung beim Tanzen und und und. Das ließ uns ein wenig vergessen, dass morgen unser letzter voller Tag in dieser aufregenden Stadt sein wird…

{ 4 comments }