Ein Phänomen, was mir sehr häufig begegnet, ist ein Bruch von Konformität. Beispiel: In einem abgegrenzten Bereich der Sourcen folgen Namensgebung und struktureller Aufbau einem bestimmten Pattern. Man findet sich gut zurecht. Urplötzlich stimmt das System nicht mehr, und die (aufreibende) Suche beginnt. Erstens nach den Dingen, die man finden möchte, zweitens nach dem Grund für den Symmetriebruch. In aller Regel ist er nicht fachlich motiviert.
Der wohl häufigste Grund ist der, dass der Code von verschiedenen Personen bearbeitet wurde. Jeder Entwickler hat seine bestimmten Vorlieben. Keine Code-Konvention ist so umfassend, dass nicht doch vielfältige Stile dabei entstehen. Wenn nun ein Entwickler einen anderen ablöst, um beispielsweise die zweite Hälfte der Domain-Objekte zu implementieren, so hält ihn erst einmal niemand davon ab, dies auf seine Art und Weise zu tun. Arbeiten mehrere Leute parallel an einer Sache, so kann es je nach Persönlichkeit der Beteiligten recht anstrengend sein, sich auf etwas Gemeinsames zu einigen. Solange niemand Konformität durchsetzt, bleibt jeder bei seinem Stil; warum auch nicht? Hauptsache man findet die eigenen Klassen „schön“.
Merkwürdig finde ich, dass es das Phänomen sogar gibt, wenn nur eine einzige Person an einem Gebiet arbeitet. Der Grund liegt wahrscheinlich in der Natur des Menschen selbst. Eigentlich mag er konforme Strukturen, in denen er sich gut zurecht findet. Aber irgendwann wird es langweilig, und man beginnt, sich an kleinen Überraschungen zu erfreuen. Das gilt nicht nur für Software, sondern ganz allgemein auch z.B. für Musik, Essen, Architektur,…
Erst kürzlich hatten wir im Projekt einen ähnlich gelagerten Fall. Viele Teile einer Software waren exakt gleich strukturiert, und so beschlossen wir später, einen Generator dafür zu entwickeln, was sich sehr ausgezahlt hat. Aber ein Fall unterschied sich fachlich ein wenig von den anderen, und ich muss zugeben, ich freute mich zunächst regelrecht: Es war mal Etwas Anderes. Im Nachhinein jedoch ergab sich folgendes Bild: Zunächst hat die Entwicklung des Sonderfalls wesentlich länger gedauert als gedacht. Zum zweiten habe ich bis heute Schwierigkeiten, mich in diesen Fall erneut hineinzudenken. Und zum dritten hätte man es natürlich auch anders lösen können. Es war schlicht der Wunsch nach dem Anders-Gearteten, was mich in diese Falle trieb.
Einen Fall, den man immer mal wieder vorfindet, sind unvollständige Refactorings. Hier mag der Grund einfach eine falsche Schätzung gewesen sein. So wurde mit dem Refactoring begonnen. Dann aber zwang ein Termin den/die Entwickler, damit aufzuhören. Dieser ist eher geneigt, die begonnene Arbeit nicht einfach zu verschenken, in der Hoffnung, das Werk zu einem späteren Zeitpunkt zu beenden. Auf diese Art und Weise verbleiben dann zwei verschiedene Implementierungen – wahrscheinlich für immer, denn sie „laufen ja“ (siehe auch „Läuft doch“).
Ein weiteres Phänomen ist das Scheuklappensyndrom. Der Entwickler ist derart auf den eigenen Usecase konzentriert, dass er sich nicht die Zeit gönnt, bei den Kollegen nachzufragen oder in verwandtem Code zu stöbern, wie dort ähnliche Fälle gelöst worden sind. Dies kann zum Teil eine schlechte Angewohnheit sein, zum Teil wird dies Verhalten natürlich auch durch anstehende Termine gefördert (siehe auch „Die bösen Termine“)