adesso Blog

Als ich letztens im Zug saß, las ich ausnahmsweise kein Buch, sondern schaute mir ein Interview mit Steve Jobs aus dem Jahr 1995 an. Steve Jobs soll hier aber gar nicht im Fokus stehen, sondern nur seine Gedanken zu Fahrrädern. Über diese erzählt er nämlich in dem Interview.

MongoDB – diese NoSQL-Datenbank ist den meisten Fachleuten bereits ein Begriff, euch auch? Die dokumentenorientierte Datenbank wurde im Gartner Magic Quadrant 2015 als Führer im Bereich der operativen Datenbankmanagementsysteme gelistet, direkt hinter den klassischen relationalen Datenbanken von Oracle, IBM und Microsoft. Auch bei adesso setzen wir MongoDB bereits seit einigen Jahren in unseren Projekten und Lösungen ein, so zum Beispiel in der MIG|Suite.

Die IT-Branche ist bekannt für ihre einfallsreichen Abkürzungen und waghalsigen Schlagwörter. Manchmal frage ich mich aber, ob es Zufall ist, dass einige Abkürzungen eine negative Konnotation hervorrufen – ACID, MongoDB oder mein Favorit HATEOAS, um nur einige Beispiele zu nennen… Oder gibt es da vielleicht einen tieferliegenden Zusammenhang zwischen der Namenswahl und der Gedankenwelt der Berufsgruppe, die diese Namen geprägt hat? Obwohl sich der Name „MEAN Stack“ in meiner Liste der Abkürzungen mit negativen Konnotationen hervorragend einreiht, ist der MEAN Stack allerdings mehr als nur „Durchschnitt“.

Was sorgt für schlanke Software? Wie können alle Beteiligten auf dieses Ziel verpflichtet werden? Shared-Pain-/Shared-Gain-Modelle sind die Antwort. Das sind Modelle, die die genannten Mechanismen umsetzen und den Gesamtfokus auf die oben geforderte schlanke Software legen.

Agile Softwareentwicklung lässt viel Spielraum für Entscheidungen – auch spät im Projekt. Das ist inhaltlich sinnvoll und in gewissen Maßen unvermeidbar, denn viele Softwaresysteme sind – abstrakt betrachtet – soziotechnische Systeme: Sie können als organisierte Menge von Menschen und Technologien verstanden werden, die in einer bestimmten Weise strukturiert sind, um ein spezifisches Ergebnis zu produzieren. Und sie sind nicht vollständig beschreibbar. Selbst der Versuch einer möglichst weitgehenden Vorab-Spezifikation ist, zumindest für Informationssysteme ohne ausgeprägte Risiken, unwirtschaftlich. Vieles lässt sich erst während der Entwicklung festlegen, direkt umsetzen und notfalls neu bewerten. Gerade das ist der Charme der agilen Entwicklung.