Continuous Architecture

Der geschätzte Aufwand eines Softwareprojekts bezieht sich meist auf das jeweilige Team. Aber Aufwand ist nicht objektiv und unabhängig vom Team schätzbar.

Softwareentwickler und Softwarearchitektinnen müssen sparsam mit Daten umgehen. Sonst entstehen Risiken, die niemand absehen kann.

Künstliche Intelligenz könnte zu einem enormen Produktivitätssprung in der Softwareentwicklung führen. Welche Auswirkungen kann das haben?

Softwareentwicklungsteams sind soziale Systeme. Auch andere Primaten bilden solche sozialen Systeme. Was können wir von den anderen Primaten lernen?

Agilität ist angetreten, produktiver Software zu entwickeln. Eine Studie zeigt aber mehr Fehlschläge. Das sagt mehr über unsere Branche aus als über Agilität.

Das Ende ist nah: Bald wird KI die Softwareentwicklung übernehmen. Das ist übertrieben und zeigt, wie unklar ist, worum es Softwareentwicklung wirklich geht.

Softwarearchitektur beeinflusst den Erfolg eines Projekts erheblich. Aber ausgerechnet "gute" Entwickler und Entwicklerinnen können Feinde der Architektur sein.

Meetings nerven! Also: abschaffen! Aber: Kommunikation ist wesentlicher Teil der Softwareentwicklung und Meetings ein wichtiges Kommunikationswerkzeug. Was nun?

Die Frage "Ist diese Software-Architektur zukunftssicher?" kann man eigentlich generell mit "nein" beantworten. Schlimmer noch: Die Frage zu stellen, kann schon auf ein falsches Verständnis von Architektur hinweisen.

Software-Entwicklung ist voller spannender Herausforderungen, und es gibt immer etwas Neues zu lernen: Software ist schließlich eine der komplexesten Dinge, die von Menschen gebaut wird. Aber die Ergebnisse in der Realität sind manchmal mehr als enttäuschend - sie sind beschämend.

Lange genug hat es geheißen, dass IT-Projekte einen Wettbewerbsvorteil versprechen. Schaut man der Realität ins Auge, wird ein IT-Projekt jedoch wie ein Kostenfaktor behandelt – nicht anders als Strom oder Miete. Dabei könnte es anders sein.

Das Wasserfall-Modell ist recht alt, aber taucht dennoch bei der Diskussion über Softwareentwicklungsprozesse immer noch sehr häufig auf. Die Geschichte dieses Modells ist weitgehend unbekannt – dabei zeigt sie die Herausforderungen des Modells und warum man es nicht nutzen sollte.

Softwaresysteme sind kompliziert. Best Practices für den Systementwurf könnten dabei helfen, die Komplexität möglichst einfach zu bändigen. Leider nützen sie wenig.

Wenn man auf Entwickler*innen nicht aufpasst, machen sie den ganzen Tag Unsinn. Wie soll man damit umgehen?

In der Softwarearchitektur nimmt die Diskussion von Zielbildern viel Platz ein – schließlich muss es ein Ziel geben, auf das man hinarbeitet. Aber die Prioritäten sollten anders verteilt sein, und eigentlich sind Zielbilder auch nicht das Ziel.

Metaphern für Softwareentwicklung gibt es viele. Sie als Spiel zu begreifen, scheint zunächst respektlos. Wenn man tiefer gräbt, ergeben sich aber zahlreiche Parallelen.

Große komplexe Projekte sind schwer zu handhaben. Software-Release-Trains sind eine Lösung zur Koordination. Aber der Ansatz läuft Selbstorganisation und modernen Management-Konzepten zuwider.

Agilität in der Softwareentwicklung wird oft unzureichend umgesetzt und gelebt. Hilft sie trotzdem?

Dank Digitalisierung sind Software und IT für die Wettbewerbsfähigkeit entscheidend. Oder ist das IT-Chauvinismus?

Agilität ist im Kern eine Menge von Werten. Passen die typischen agilen Begriffe eigentlich zu den Werten oder führen sie eher zu Missverständnissen?