PUBLIKATIONEN

Kolumne von Joachim Arrasz – Be pragmatic, not dogmatic

jaxenter Logo

"Softwarearchitekten sind zu teuer, sowas muss ein erfahrenes Team selbst hinbekommen" – Teil 8

Dogmatismus wie auch Pragmatismus werden oft als Ausrede für verschiedene Unarten innerhalb der Softwareentwicklung genutzt. In dieser Kolumne wollen wir verschiedene Beispiele für beides vorstellen und hoffentlich spannend diskutieren. Heute geht es um die beiden Haltungen: "Softwarearchitekten sind zu teuer, sowas muss ein erfahrenes Team selbst hinbekommen" vs. – "Mein Team soll seine Fachdomäne verstehen und muss keine Technologie-Experten hervorbringen"... (mehr lesen)


Kolumne von Joachim Arrasz – Be pragmatic, not dogmatic

jaxenter Logo

Modulare Anwendungen sind nur für größere Projekte gut – sonst lohnt sich der Mehraufwand nicht – Teil 7

In diesem Teil werde ich ein Dilemma besprechen, welches mir seit Jahren immer wieder begegnet: die Tatsache, dass Systemgrenzen nicht erkannt oder aber nicht eingehalten werden. Wer kennt das nicht: Man schaut sich eine Software an und stellt fest, dass man eigentlich drei unterschiedliche Systeme in einem vor sich hat... (mehr lesen)


jaxenter Logo

Ein String ist immer ein String, oder doch ein Passwort? – Teil 6


In diesem Teil werde ich ein technisches, eigentlich sehr einfaches, aber doch spannendes Thema, welches mich die letzten 10 Jahre immer wieder anstrengt, diskutieren ... Los geht es also mit dem inzwischen 6. Teil der Kolumne. Ich war beratend bei einem Kunden vor Ort, wo es darum ging, für zukünftige Projekte, welche alle "gleich sein werden", Entwicklungsstandards zu diskutieren und dann festzulegen. Natürlich bemerkten wir schnell, dass die Projekte eben doch nicht "gleich" sind. Die Ähnlichkeit innerhalb der Projekte war aus Sicht des Kunden über die selben Usecases gegeben. (mehr lesen)


jaxenter Logo

Modernes Tooling versus etablierte Best Practices – Teil 5


Steigen wir also in den fünften Teil der Kolumne ein. Jeder Softwareentwickler hat sicherlich schon das eine oder andere Mal Begriffe wie "Blueprint Architecture", "Masterarchitekturplan" oder dergleichen gehört.

Die allermeisten meiner Kollegen zucken bei diesen Begriffen unweigerlich erschreckt zusammen. Nur warum ist das so? Architekturvorgaben, und letztlich sind solche Dokumente exakt dieses, haben das Ziel, zu vereinheitlichen. Es geht darum, Dinge, die immer wiederkehren, zu identifizieren, zu strukturieren und zu regulieren. Dies sind also alles Qualitäten, die derzeit innerhalb eines anderen spannenden Themas, des Continuous Deployments, hoch gelobt werden und zwingende Grundvorraussetzung dafür sind. Warum also werden Dokumente, welche diese Qualitäten unterstützen, für so problematisch angesehen? Kommen wir zu einem Beispiel... (mehr lesen)


jaxenter Logo

Sitzen wir nicht alle im selben (Software)-Boot? Teil 4


Steigen wir also in den vierten Teil der Kolumne ein, in dem ein Thema besprochen wird, welches meiner Meinung nach in nahezu jeder Produktion oder Fertigung, die Software-gesteuert arbeitet, vorkommt: Wo beginnen die Kompetenzgrenzen des Entwicklungsteams, wo enden die Kompetenzen des Maintenance-Teams?

Begonnen hat alles damit, dass das Entwicklungsteam, wie geplant, ein Release deployed hat. Das Deployment lief auch rund, die ersten zwei Monate lief die Anwendung wie erwartet. Nach und nach traten kleine Performance-Probleme zu Tage, da das System nun mehr und mehr Produktionsdaten halten musste. Der Betrieb des Systems wurde von einer anderen Abteilung realisiert. Das Entwicklungsteam hatte dazu einen Deployment-Plan erstellt und diesen, wie auch das Systemarchitekturdiagramm, an die Abteilung, welche den Betrieb realisiert und zu verantworten hat, übergeben. (mehr lesen)


jaxenter Logo

Deployment-Abläufe sind ein wichtiges Ziel für Entwickler, aber interessiert das den Kunden? Teil 3


Los geht es also nun mit dem dritten Teil der Kolumne. Dieses Mal ist es, meiner Meinung nach, eine spannende Mischung aus technischen und geschäftsrelevanten Themen.

Innerhalb eines von uns seit einigen Jahren betreuten Kundenprojektes wurde nach einigen Auslieferungen und Deployments immer klarer, dass die IT-Infrastruktur wie auch die Auslieferungszyklen für die angeforderte Qualitätssicherung nicht ausreicht. Nach einigen Diskussionen wurde beschlossen, dass wir zukünftig ganz klassische Abläufe "Develop ? Test ? Stage ? Production" installieren werden. (mehr lesen)


jaxenter Logo

Die zwei Gesichter der Agilität – Teil 2


Steigen wir also in den zweiten, dieses Mal nicht sonderlich entwicklungslastigen Erfahrungsbericht ein.

Wir arbeiteten mit einem Kunden seit Monaten an einem größeren Code-Clinic-Projekt, in dem wir während des Betriebs nach und nach fachliche Teile der Anwendung refactored und mit einer neuen technischen Servicearchitektur versahen. Von Beginn an wurde der Aufwand im technischen Stack so klein wie möglich und so groß wie nötig gehalten. Es war einfach noch viel zu wenig Erfahrung aus dem bereits acht Jahre laufenden Projekt vorhanden, um wirklich bewusst eine sinnvolle Architekturentscheidung zu treffen. (mehr lesen)


jaxenter Logo

Be pragmatic, not dogmatic! Teil 1


Dogmatismus wie auch Pragmatismus wird oft als Ausrede für verschiedene Unarten innerhalb der Softwareentwicklung genutzt. In dieser Kolumne wollen wir verschiedene Beispiele für beides vorstellen - und hoffentlich spannend darüber diskutieren!

Die Idee zu dieser Kolumne entstand über viele Jahre hinweg durch Gespräche mit Entwicklern, Senior-Entwicklern und Software-Architekten - oder Menschen, die dies sein wollten oder sollten. Ja, oftmals wird einem solch eine Rolle einfach aufgestempelt, unfassbar, oder? :-) Aber auch die Menschen in den Anzügen sollen hier ihr Recht erhalten. Ich werde das eine oder andere Thema aufgreifen, bei dem sich sicherlich manch ein Manager, der mit den vorhin genannten zu tun hat, bestätigt fühlt. Lasst euch überraschen... (mehr lesen)


synyx GmbH & Co. KG

Open Source Solutions

Gartenstraße 67
76135 Karlsruhe

+49 721 203823-0 +49 721 203823-12