Fangen Sie bitte nicht mit diesem Thema an

Ungeschriebene Gesetze

David Platt

Die Softwarebranche wie die moderne Gesellschaft im Allgemeinen wird durch viele ungeschriebene Gesetze geleitet, und mit der Zeit werden es immer mehr. Je älter und intelligenter ich werde, desto zynischer werde ich auch, desto deutlicher kann ich erkennen, dass sowohl die Gesellschaft als auch die Softwarebranche tatsächlich eher durch ungeschriebene Gesetze als durch niedergeschriebene bestimmt wird.

Das niedergeschriebene Gebot besagt: "Du sollst nicht x!" Das ungeschriebene Gesetz besagt: "Ja, du kannst x – mindestens unter bestimmten Umständen. Sie müssen irgendwie, um die Arbeit zu erledigen." Im ersten Gesetz wird die Welt so angesprochen, so wie sie nach Ansicht des Autors sein sollte, im zweiten wie sie tatsächlich ist.

Kompliziert? Ja. Differenziert? Selbstverständlich. Probleme? Häufig. Aber beobachten Sie beim nächsten Mal die Gewerkschaften von Verkehrspiloten oder Krankenschwestern, die einen Dienst nach Vorschrift vornehmen, anstelle zu streiken. Ohne diese ungeschriebenen Gesetze verlieren ihre Arbeitsplätze schnell an Sicherheit. Und ähnliches würde für die Gesellschaft gelten, wenn wir die ungeschriebenen Gesetze anstelle der niedergeschriebenen nicht befolgen würden.

Denken Sie nur an Michael Pineda, den Pitcher der New York Yankees, der im April für zehn Spiele gesperrt wurde, weil er Holzteer an seinen Fingern verwendete, um den Ball besser greifen zu können. Das niedergeschriebene Gesetz besagt, Pitcher dürften weder Holzteer noch eine andere Substanz verwenden. Das ungeschriebene Gesetz besagt hingegen, dass ein wenig Holzteer bei kaltem Wetter in Ordnung ginge, solange es niemandem auffalle. Pineda wurde weniger für die Verwendung des Holzteers bestraft, sondern vielmehr für seinen plumpen Versuch, der den Schiedsrichtern nicht entging (Infos hierzu finden Sie unter foxs.pt/1i3R3fz).

Um ein Beispiel aus unserer Branche zu bemühen … Objektorientierte Programmierer haben globale Variablen lange Zeit als Tabu erklärt. Jeder, der nur daran dachte, sollte bestraft werden, richtig? Wodurch wird eine statische Klasse auf der anderen Seite mit Ausnahme einer globalen, die in Wrappern verschleiert ist, politisch korrekt? Programmierer hängen Sie oftmals aus einer Objektklasse namens "Globals". Wenn nur eine Instanz eines Elements in einem Programm vorhanden ist und es sich dabei um eine Ganzzahl handelt, wie viele Abstraktionsschichten, Manager und Dienste soll ich dann verschleiern, damit Sie sich wohlfühlen? Oder kurz gesagt: Wie viele Schichten möchten Sie mir bezahlen, wenn Sie dieses Geld für etwas anderes verwenden könnten? Ihr Scheck ist Ihre Antwort. Und sie ist wahrscheinlich anders als die erste Reaktion vor zwei Sätzen.

Manchmal besteht die niedergeschriebene Regel nur darin, das bereits vorhandene ungeschriebene Gesetz aufzuschreiben. Das feste Verbinden einer Zeichenfolge, wie beispielsweise eines Dateinamens, direkt in Ihrem Code ist für gewöhnlich keine gute Idee, aber manchmal führt kein Weg daran vorbei. Verpassen Sie dieser Konstruktion eine wohlklingende Bezeichnung, und schon ist alles in Butter.

"Wir befolgen das Entwurfsmuster mit dem wohlbekannten Namen", sagt der Streber. "Gut, gut", sagt der nicht technisch veranlagte Chef. "Ich bin froh, dass Sie Entwurfsmuster verwenden und nicht diese wilde Codierung, von der ich gehört habe."

Leute, Sie stellen eine feste Verbindung in einer Zeichenfolge her. Machen Sie das, wenn Sie müssen, passen Sie aber auf, Sie müssen es nur gut durchdacht haben. Zudem sollten die Vorteile die Kosten überwiegen. Beruhigen Sie sich mit der Lüge, dass Sie das eines Tages beheben werden, wenn Sie Zeit dazu haben. Aber denken Sie nicht, Sie ändern die Funktionsweise durch Verschleierung des Namens. Ein Fehler behindert und frustriert Ihren Benutzer, auch wenn Sie den Fehler als Problem ausrufen (siehe msdn.microsoft.com/magazine/ff955613).

Beim Software Engineering geht es darum, einen Mittelweg zu finden, wann die niedergeschriebenen und wann die ungeschriebenen Gesetze verwendet werden sollten. Es gibt einige absolute Gebote nach dem Muster "Du sollst nicht" in diesem Geschäft (auch wenn das Nichtverschieben einer Marquee-Zeichenfolge auf der Statusleiste Ihres Browsers dem verdammt nahekommt). Ich erinnere meine Kunden und Studenten immer wieder an eine Sache: "Sie sollen nachdenken. Wenn es schwer ist, dann sollen Sie mich dafür bezahlen, dass ich Ihnen beim Nachdenken helfe."

Ich bin neugierig, von Ihren bevorzugten ungeschriebenen Gesetzen der Softwareentwicklung zu hören oder wovon auch immer, solange es thematisch passt. Senden Sie sie mir an dave@rollthunder.com.

Ich bin mir sicher, dass irgendein pedantischer Streber nun sagen wird, die von mir hier aufgeschriebenen ungeschriebenen Regeln seien nun nicht mehr ungeschrieben. Was ich gleichzeitig zerstreuen kann: Sie brechen mein ungeschriebenes Gesetz durch die Gewissenhaftigkeit Ihres übertreibenden Rückseitenkolumnisten. Dafür ist eine Sperre über zehn Spiele angemessen, oder?

David S. Platt unterrichtet Programmieren mit .NET an der Harvard University Extension School und in Unternehmen auf der ganzen Welt. Er ist Autor von 11 Büchern zum Programmieren, darunter "Why Software Sucks" (Addison-Wesley Professional 2006) und "Introducing Microsoft .NET" (Microsoft Press 2002). Microsoft ernannte ihn im Jahr 2002 zur "Softwarelegende", und er überlegt, ob er seine Tochter das Zählen im Oktalsystem lehrt. Sie erreichen ihn unter rollthunder.com.