Kategorie: Eponymous Laws

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 den Sprecher. Einen ähnlichen Effekt gibt es auch in

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, der eigentlich wichtige Bereich der Qualitätsanalyse und der Verarbeitungprozesse

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, als korrekt ansehen. Die Aussagen über zukünftige Trends und

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 beispielsweise eine Firma negative Abweichungen bei den Implementierungsaufwänden durch

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 Industrie zu.

Weiterlesen

Conway’s law

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

Weiterlesen

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. !(color != BLACK && color != WHITE) || color == WHITE Häufige verweisen die Entwicklern auf den Optimierungen des Compilers, wenn sie ihre

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.

Weiterlesen

Kaiser’s Razor

Never assume software developer skills when stupidity will suffice 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.

Weiterlesen

Atwood’s Law

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

Weiterlesen