Mittelstand, Finger weg von Microservices!

Was Accidental Complexity in der Entwicklung kostet

Anfangs setzen IT-Teams schnell neue Features um, dann wird die Entwicklungszeit meist länger. Accidental Complexity ist häufig die Ursache – wir erklären, wie sie entsteht und was sich dagegen tun lässt.

Es ist kein Geheimnis, dass Systeme über die Zeit komplexer und damit die Entwicklungszeiten länger werden. Das ist nicht zu vermeiden, wenn das Problem inhärent komplex ist, man spricht dann von Essential Complexity. In anderen Fällen wird die Umsetzung eines Features komplexer, als es sein müsste. Zwei Monate für ein eigentlich einfaches Feature? Ein klarer Fall von Accidental Complexity. Sie ist ärgerlich, kostet viel – und ist vermeidbar, wie wir an einigen praktischen Beispielen zeigen.

Marcus Held

Two More Billion Dollar Mistakes

Hi,

Du hast bestimmt schon mal mitbekommen, dass null von seinem Erfinder Tony Hoare als “Billion Dollar Mistake” bezeichnet wird. 2009 entschuldigte er sich auf der QCon öffentlich, dafür dass er 1965 den leichten Weg gegangen ist und null erfunden hat:

“I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object-oriented language (ALGOL W ). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn’t resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.”

---

Marcus Held

My War on Kubernetes

Hi,

Ich muss direkt ein Geständnis machen: Ich bin auf Kriegsfuß mit Kubernetes.

Dabei trifft Kubernetes gar keine Schuld. Meine Projekte sind es. Beziehungsweise die Teams, in denen ich mich bewege.

Es sind Teams mit maximal 30 Software-Entwicklern, noch ein paar Business-Menschen und Designer oben drauf. Aber es sind nicht soooo viele Entwickler.

Diese Teams brauchen kein Kubernetes!

Nein. Noch deutlicher: Diese Teams können kein Kubernetes halten!

“Aber Marcus. Das ist doch kein Problem. Ich habe das doch schon bei XY gemacht, und es war so einfach, wenn man sich an YX hält und das ZY-Prinzip einhält.”

Marcus Held

Survivorship Bias in Tech

Hi,

Kennst du das Survivorship Bias?

[…] Nach dem Survivorship Bias werden Wahrscheinlichkeiten eines Erfolgs systematisch überschätzt, da erfolgreiche Personen oder Zustände stärker sichtbar sind als nicht erfolgreiche. ~ Wikipedia

Diese kognitive Verzerrung ist interessant, weil sie uns auch in der Entwicklung betreffen. Seit 15 Jahren arbeite ich hauptsächlich im Mittelstand. Das sind Unternehmen bis 250 Mitarbeiter. Also ganz klar keine Großunternehmen.

Und letzte Woche habe ich darüber geschrieben, dass die Größe der Entwicklungsteams im Mittelstand sehr ähnlich ist.

(hier geht’s zum letzten Newsletter )

Marcus Held

Challenges in SMEs Are Similar

Hi,

Aktuell schreibe ich an einem neuen Artikel für Golem.de.

Und in diesem Zusammenhang habe ich über die Gemeinsamkeiten in der Softwareentwicklung in kleinen und mittleren Unternehmen (KMU) nachgedacht.

Das Statistische Bundesamt definiert KMU als Unternehmen von 10 bis 250 Mitarbeitern und einem Umsatz unter 50 Millionen Euro.

Jetzt ist die Spanne auf den ersten Blick sehr groß. Intuitiv erwartet man, dass die Herausforderungen und Lösungen deswegen auch sehr unterschiedlich aussehen sollten. Und das stimmt zum Teil natürlich. Aber es deckt sich nicht mit meiner Erfahrung der letzten 15 Jahre, in denen ich ausschließlich in KMUs gearbeitet habe. Wenn man nämlich genauer hinschaut, dann stellt man fest, dass die Anzahl an Entwicklern gar nicht mehr so weit auseinander geht.

Marcus Held