Wichtig, Wichtiger, am Wichtigsten – der Lombard Effekt

Wer schon einmal auf einer Party gewesen ist, wird dieses Phänomen sicherlich kennen. Viele Menschen unterhalten sich und es ist sehr laut. Damit der Gegenüber versteht was man ihm zu sagen hat, muss man lauter und höher sprechen als gewöhnlich. Dieses Phänomen nennt sich Lombard Effekt und ist begründet in der eingeschränkten akustischen Rückkopplung für … Weiterlesen

Parkinson’s Law of Triviality

Wer von dem Pech verfolgt wird, anderer Leute Projekte realisieren zu müssen, bemerkt nach einiger Zeit eine Regelmäßigkeit in den erstellten Papieren. Die Autoren beschäftigen sich mit einer akribischen Genauigkeit um Randthemen der Projekte und lassen wichtige Aspekte der Domäne völlig unberührt. Vor Jahren musste ich mir detailreiche ER Modelle für eine unbedeutene Teileverwaltung anschauen, … Weiterlesen

Clarke’s First Law

„When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.“ Statt Wissenschaftler kann man hier auch IT-Leiter, Projektleiter, Architekt oder Software Entwickler einsetzen. Die Aussagen, die sich um die Nutzung erworbenen Wissens drehen, kann man ruhigen Gewissens, … Weiterlesen

Goodhart’s law

„Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes.“ Was Charles Goodhart für den Markt als Gesetzmäßigkeit feststellte, gilt auch für beliebige Organisationen und damit auch für Software Entwicklungsabteilungen. Eine andere Formulierung des Gesetzes lautet „Wenn ein Maß zum Ziel wird, ist es kein gutes Maß mehr“. Versucht … Weiterlesen

Sturgeon’s Law

„90 per cent of everything is crap.“ Ursprünglich wurde dieses Gesetz von Theodore Sturgeon zur Verteidigung der Science Fiction Literatur aufgestellt. Den Hinweis auf die mindere Qualität vieler SF Romane konnte Sturgeons mit der Beobachtung relativieren, dass auch in allen anderen Bereichen fast nur Mist produziert wird. Leider trifft Sturgeon’s Law auch auf die Software … Weiterlesen

Conway’s law

Any piece of software reflects the organizational structure that produced it.

Conway’s law

Zauberei mit Wahrheiten

Haben Sie manchmal auch das Gefühl, dass ihre Kollegen Angst vor boolschen Ausdrücken haben? So mancher scheint die De Morganschen Gesetze wie die dunklen Zauberkünste einer Morgan le Fay zu fürchten. So bleiben dann auch Ausdrücke, wie der folgende, für Ewigkeiten im Programmcode. Häufige verweisen die Entwicklern auf den Optimierungen des Compilers, wenn sie ihre boolschen Ausdrücke … Weiterlesen

Brooks’ law

“Adding manpower to a late software project makes it later.”

Neue Mitarbeiter in Projekte hineinzustecken bedeutet immer zusätzliche Kommunikation und die Produktivität des Teams wird reduziert, weil es die neuen Mitarbeiter einarbeiten muss. Wenn das Team dann schon dem Zeitplan hinterherläuft, wird die Situation nur schlimmer. Außerdem ist oft das Team schon groß genug und die Entlastung durch neue Mitarbeiter geringer als der Einarbeitungsaufwand. Für ausreichend große Teams gibt es daher folgende lustige Variante dieser Regel

“Eine Frau braucht neun Monate um ein Baby zu bekommen; neun Frauen auch”

Kaiser’s Razor

Never assume software developer skills when stupidity will suffice

Jens Kaiser

Basierend auf Hanlon’s Razor und dem Paretoprinzip,  besagt diese Regel, dass man grundsätzlich von fehlerhaften Sourcecode ausgehen sollte. Man investiert ansonsten zu viel Zeit, um nicht vorhandene Design-Pattern oder absichtsvolle Algorithmen zu entdecken.

Atwood’s Law

Any software that can be written in JavaScript will eventually be written in JavaScript.