The Simplificator blog

Nachdem wir im Juni Sabine und Fabian begrüssen konnten, hat im Juli nun Thomas bei Simplificator angefangen.

Bilder und Kurzbiographie folgen, das Photoshooting findet heute statt:-)

Anfang Juni ist das Simplificator Team gleich um zwei Mitarbeiter gewachsen.

Sabine unterstützt uns in den Bereichen Konzeption, Design, Grafik und Projektleitung. Somit kann Simplificator nun erstmals alles aus einer Hand bieten. Von der Idee bis zum fertigen Produkt.

Fabian verstärkt unser Team mit seinem Knowhow und Erfahrung in der Softwareentwicklung.

Wir können bei unseren Nachbarn, dem Punkt Magazin, das Photostudio benutzen, so dass hoffentlich bald alle Bilder aktualisiert sind.

Sicher ist sicher oder eben auch nicht. Wer einen Router hat und dessen Passwort nicht zurücksetzt, sollte sich nicht wundern, wenn der freundliche Nachbar sich an der Konfiguration zu schaffen macht.

Eine typische Situation nach den ersten Erfolgen mit einer Applikation: Das Team ist langsam, wehrt sich gegen Anforderungen. Neue Funktionen sind schwierig umzusetzen, und die Testphasen werden länger. Die Software-Entwicklung wird immer schwieriger.

Architektur einer Applikation ist eine relativ abstrakte Angelegenheit: Oft von technologischen Überlegungen getrieben, mit dem Wunsch eine allgemeine Lösung für alles zu haben. Auf der einen Seite gibt es den Hacker-Ansatz - auf eine schnelle, unspezifische Weise möglichst schnell zum Ziel zu kommen. Es gleicht einem Basar - alles geht irgendwie, es ist effizient - aber die Systeme sind schwierig zu warten weil die Struktur fehlt. Auf der anderen Seite gibt es die Architektur-Astronauten - sie haben ein Buch (oder mehrere) gelesen, sind überzeugt von dem Wert von Struktur, aber sie überborden: Grundlos bauen sie virtuelle Kathedralen, flechten Schichten über Schichten, machen alles extrem “flexibel” und verlieren die Entwicklungsgeschwindigkeit.

Der Hauptgrund ist die Komplexität der Aufgabe. Architektur ist nötig, aber schwierig, und muss der Aufgabe angepasst sein. Es ist nicht einfach objektive Bewertungskriterien zu finden, verschiedene Architekturen zu beurteilen. Dazu kommt, dass Architekturanpassungen normalerweise viel Aufwand bedeuten, ohne dass eine Applikation an Funktionalität gewinnt. Damit entscheiden sich Betriebe oft dazu, eine bestehende Architektur beizubehalten und mit den Problemen umzugehen.

Wie wäre es hingegen, wenn Entwickler eine klare Idee haben, wie ein System idealerweise umgesetzt würde? Wenn die Technologie-Entscheide vom Bedarf getrieben werden statt von Glaubenssätzen von Architektur-Astronauten? Wenn die Entwicklungsgeschwindigkeit Schritt für Schritt zunimmt, die Fehlerrate abnimmt, das Team mehr Produktivität gewinnt, und die Fähigkeit schnell zu reagieren? Wenn Sicherheitsprobleme erkannt werden, bevor ein Problem auftritt?

Die zentrale Aufgabe ist, mit der Komplexität kontrolliert umzugehen. Komplexität lässt sich nicht wegdiskutieren. Es gibt die inhärente Komplexität der Aufgabe, und es gibt die Komplexität des Systems. Die effizienteste Lösung ist, wenn die Komplexität der Aufgabe sauber modelliert wird - dies wird die zentrale Architektur. Gleichzeitig soll die Komplexität des Systems so klein wie möglich gehalten werden.

Durch Refactoring kann diese Aufgabe auch später in der Entwicklung angegangen werden. Refactoring ist die Verbesserung der Struktur einer Applikation ohne der Veränderung der Funktion. Wenn die Architektur aus Refactoring entsteht, ist sie im Allgemeinen sinnvoll - sie hat eine Berechtigung von bestehendem Code her. Refactoring kann auch unnötige Komplexität reduzieren - wenn zu viele Schichten vorhanden sind in der Software, kann damit wieder Übersicht geschaffen werden.

Durch Code Reviews können verschiedene Sichtweisen eines Problems berücksichtigt werden: Code Reviews können zum Beispiel aufdecken, wenn defensiv programmiert wird. Defensive Programmierung ist wenn Teile des Programms anderen Teilen “nicht glauben” dass sie sich anständig verhalten, und versuchen auf unerwartetes zu reagieren. Das bläht den Code auf. Code Reviews helfen, solche Strukturen zu erkennen und die Probleme zu lösen.

Durch automatisierte Qualitätssicherung (Unit Tests und ähnlichem) können zentrale Funktionen gesichert werden, sodass die Testphase strukturierter und kürzer wird, und die Fehlerrate sinkt.

Wir bieten eine Beratung an, wo die Architektur eines Systems optimiert wird. Folgende Schritte können sinnvoll sein.

1. Code Review: Wir können in der ersten Stufe das System bezüglich Sicherheit, innerer Qualität, Modernität und Flexibilität beurteilen. Wir machen hierzu ein Code Review. Das Resultat ist ein Dokument, eine Arbeitsliste von Punkten wo gearbeitet werden soll, und allfällige Sicherheitsbedenken, die separate untersucht werden soll.

2. Architekturberatung: Wir beschreiben wie das System so verbessert werden kann, dass es besser für die Zukunft gerüstet ist. Wir schlagen Technologien vor und haben Beispiele dazu. Wir können die Entwicklungsprozesse optimieren helfen, und Vorschläge zum Umgang mit Anforderungen und Fehlern geben.

3. Coaching: Wir coachen die Entwickler, bezüglich Ressourcen, Büchern, Webseiten, welche diese Technologien und Architekturentscheidungen unterstützen können.

4. Qualitätssicherung: Wir können die Qualitätssicherung mit Unit Tests ermöglichen, sodass alte Fehler nicht mehr wiederkommen, und das Team höhere Sicherheit gewinnt beim Anpassen der Software.

5. Entwicklungsbegleitung: Wir begleiten nach Wunsch das Team von der Umsetzung bis zum fertigen Deployment.

Wir können in einem unverbindlichen Gespräch ein angepasstes Angebot formulieren. Wir können dies spontan machen oder etwas abmachen. Und wir haben guten Kaffee. Ruf an.

Jetzt. :-)

Kontakt: 044 500 47 50, info@simplificator.com oder @simplificator. Wir freuen uns.

Über die Zusammenarbeit von Evita und LUKS wird auch auf 20min.ch berichtet.

Mamagenda.ch, ein Angebot von TravailSuisse, wird neu von Simplificator betreut, gehostet und gewartet.

Mamagenda ist eine digitale Agenda zur Betreuung von schwangeren Mitarbeitern.

Das Pilotprojekt der HNO-Abteilung des Luzerner Kantonsspitals mit Evita, einem kostenlosen Service von Swisscom, bietet Patienten die Möglichkeit, auf ihre persönlichen Spitaldokumente aus der HNO sicher und jederzeit über das Internet zuzugreifen.

Simplificator hat bei der Implementierung der Schnittstelle mitgearbeitet und wir freuen uns, dass das Projekt nun in die Pilotphase übergegangen ist.

Details finden Sie hier.

Ist es nicht viel zu teuer in der Schweiz Software zu entwickeln? Sätze in Indonesien, Indien, China oder Polen sind Faktoren tiefer als in der Schweiz. Warum müssen wir denn hier entwickeln? Mit Skype und allem müsste es doch einfach sein, im Ausland zu entwickeln - so kostengünstig dass eventuelle Kostenabweichungen oder Ineffizienzen überwunden werden können. Irgendwas stimmt mit dieser Rechnung offenbar nicht.

Es gibt es mehr und mehr Entwicklungen die wieder in der Schweiz gemacht werden. Die Industrie ist gesund, alle Software-Bauer suchen Entwickler, in den verschiedensten Technologien. Offenbar ist es doch nicht so einfach im Ausland zu entwickeln: Wir kennen viele Projekte, die fehlschlugen oder nahezu fehlschlugen, frustrierte Kunden, Entwickler die schlechten Code pflegen und wütend unter Zeitdruck Bugs von anderen fixen müssen, und mit etwas Wohlwollen finden wir vielleicht eine einzelne Referenz von einem gelingenden Projekt. Warum diese Diskrepanz? Es müsste doch gehen, es müsste doch günstiger sein, seid ihr Softwareentwickler denn alle nicht interessiert daran?

Das Problem daran ist, dass solche strategischen Entscheide nicht von denselben Personen gefällt werden, welche die technischen Entscheide fällen. Die Recheneinheit ist die Mannstunde oder der Manntag. Klar ist jedem bewusst dass eine Mannstunde in Indien nicht dasselbe heissen muss wie in der Schweiz. Aber die Mannstunde hält immer noch hin als “Proxy” für reale Entwicklungsleistung. Und das ist der Kern des Problems: Was wenn ich behaupte, der Overhead von Missverständnissen, Bürokratie, falsch verstandenen Aufgaben und blanker Unfähigkeit beim Auftragnehmer kombiniert einen Faktor fünf bis zehn ausmacht? Wie sieht es dann aus mit dem Kostenvorteil?

Pascal Betz und ich haben 2006 zusammen vor der Gründung von Simplificator einige Projekte in Bangalore, Indien durchgeführt, für unseren Schweizer Arbeitgeber. Wir haben dabei gelernt, was die Probleme sind: Kommunikation, Organisation, fehlender gemeinsamer Kontext. Diese Aspekte sind wichtiger, als wir uns vorgestellt haben. Software zu bauen ist nicht nur eine technische Herausforderung, sondern eben vor allem eine menschliche. Wir bauen nicht einen einzelnen Prozess auf, den wir dann wiederholen können (wie zum Beispiel bei industrieller Produktion von iPhones). Wir betreiben nicht nur Bau, sondern auch Forschung, Entdeckung, Planung. Und das sind genau die Dinge die in der Übersetzung verlorengehen - sozusagen “Lost in Translation”. Die Komplexität die in Softwareentwicklung inhärent ist trägt dazu bei, dass die wahren Probleme nicht wahrgenommen werden: Es ist so einfach zu sagen dass der Auftrag nicht klar genug formuliert worden ist, oder dass Softwareentwicklung halt mit Risiken verbunden ist.

"Und sowieso habt ihr ja den Vertrag so unterzeichnet und dort steht das ja genau so wie wir ihn erfüllt haben - wie kann es denn unser Fehler sein wenn ihr uns nicht sagt was ihr braucht."

Genau. Danach können nur noch Anwälte Geld verdienen. Zurück zur Schweiz:

Wie wäre es, wenn Softwareentwicklung wieder als Arbeit verstanden werden könnte, nicht als Magie, zu erledigen von abstrakten Ressourcen, die ihre Manntage in Cubicles irgendwo auf der Welt als erledigen, sondern Menschen mit denen man reden kann? Die regelmässig mit Papier und Bleistift Annahmen klären, Dinge visualisieren, den Auftraggeber zurück in die kontrollierende Position rücken? Die die Fragen fragen die sie interessieren, expliziter von implizitem Bedarf unterscheiden? Statt Jaja-Sklaven echte Diskussionspartner, die teure Fehlentscheidungen rechtzeitig hinterfragen, Rückfragen, keine Angst haben die grossen Entscheidungen anzuzweifeln?

Der Ausbildungsstandard in der Schweiz ist hoch. Wir haben ein Qualitätsverständnis, und eine Ehrlichkeit. Wir haben weniger Hierarchiegläubigkeit als andere. Das macht es vielleicht am Anfang des Projektes anstrengender, aber dafür kommt etwas dabei raus. Als wir das herausgefunden haben, haben wir verstanden dass wir in der Schweiz eine Chance haben mit einer eigenen Firma.

1. Die Kosten pro Stunde sind höher. Aber die Effizienz eben auch.
2. Wir sehen dass Komplexität nicht weg-abstrahiert werden kann, sondern gemanagt werden muss. Also steht und fällt der Erfolg mit der Fähigkeit, mit Komplexität umgehen zu können.
3. Persönliche Treffen haben die höchste Bandbreite von zwischenmenschlicher Kommunikation.
4. Papier und Bleistift sind immer noch durch nichts zu ersetzen.
5. Agile, iterative Entwicklung verlangt nach dauernder Kommunikation und Anpassung der Ziele.
6. Der Umgang mit Komplexität verlangt nach agiler, interaktiver Entwicklung.
7. Wenn es einfach wäre, hätten wir keinen Job. Der Umgang mit der Komplexität ist der Kern unserer Arbeit.

Deswegen heisst die Firma Simplificator GmbH.

Damit bekommen wir einen finanziell wertvollen Standortvorteil in der Schweiz, verstärkt durch Anwendung von agilen Technologien und Vorgehensweisen. Darum müsste es klappen.

Und es hat geklappt.

Was heisst das nun?

Es heisst, dass es finanziell schlau sein kann, in der Schweiz zu entwickeln, und dass das nicht ein bequemer Luxus ist, sondern ganz konkret mit dem Schaffen von realen Werten zu tun hat. Software die vor Ort mit guten Partnern entwickelt wird, ist summa günstiger. Das mag wegen oben genannten Gründen nicht von Anfang an sichtbar sein. Aber unsere Erfahrung und diese Überlegungen schaffen nicht nur ein emotionales, sondern auch ein rationales Argument für die Entwicklung von Software in der Schweiz.

Und jetzt kommt der sogenannte "Call to action": Wir können auch einfach mal drüber sprechen, es muss nicht gleich ein Projekt daraus entstehen. Wir beraten auch, machen Qualitätssicherung, oder Hosting in der Schweiz. Und wir haben guten Kaffee. Ruf an.

Jetzt. :-)

Kontakt: 044 500 47 50, info@simplificator.com oder @simplificator. Wir freuen uns.

1. Mai, ich kann ausschlafen da ein Feiertag. Das Telefon klingelt mit einer Nummer aus England.

Ich: Hallo?
Er: Yes hello Mr. B. My Name is X from Y. I believe you speak english?
Ich: yes?
Er: I’m calling because
Ich: Hold it. I’m not interested. Thank you very much. Und aufgehängt.

5 Sekunden später klingelt das Telefon wieder…und natürlich hätte ich es hier einfach klingeln lassen können. Aber das kam mir irgendwie nicht in den Sinn:-)

Ich: I’m not interested in whatever you are trying to sell. 
Er: I’m not selling anything we are ….
Ich: I’m not interested thank you. Und aufgehängt.

5 Sekunden später klingelt das Telefon wieder…

Ich: WHAT PART OF “I’m not interested” DID YOU NOT UNDERSTAND?
Er: But i need to report why you are not interested
Ich: That is none of your fu*** concern! I’m not interested. (So langsam bin ich doch etwas genervt weil mich der Typ geweckt hat)
Er: Well then go fu** yourself.

Und ja… ich hatte recht. Ich möchte nicht mit der Firma arbeiten:-)

Wenigstens ein paar der neuen Poster hängen schonmal. Das “Less Meetings more Doing” wird wohl in unser Besprechungszimmer kommen:-)