Negativ:
Das gibt es sogar innerhalb von Projekten. Mitarbeiter trauen dem Code des Kollegen nicht, wollen sich nicht in "fremden" Code einarbeiten, sind zu faul, die Funktionen im System zu suchen oder das Design auf Wiederverwendbarkeit abzustimmen, usw...
Die Folgen: SpaghettiCode, ErkerUndTürme am Programmgerüst, mehrere Frameworks für die gleiche Aufgabe! Wiederverwendung wird in so einem Umfeld allenfalls geduldet, aber nicht unterstützt.
Dabei ist Wiederverwendung gar nicht so schwer. Über Coaching, ProgrammierenInPaaren und BrownBagMeetings kann Wissen über die gemeinsame Codebasis verbreitet werden. Über Komponentendesign und InkrementelleEntwicklung? mit stetiger Aktualisierung des DV-Konzepts (bzw. der UML-Modelle) findet Wiederverwendung auf den nächsthöheren Ebenen statt und irgendwann verkauft man gar dem Kunden Komponenten anstatt von Anwendungen.
Code über Projektgrenzen hinweg zu verwenden ist dagegen enorm schwierig und erfordert einiges an Zusatzaufwand. Im Grunde funktioniert das nur, wenn die Produktentwicklung maßgeblich firmenintern getrieben ist. So funktioniert Standardsoftware. Bei Auftragsarbeiten wird jeder Kunde ein speziell auf ihn zugeschnittenes Produkt verlangen. Das designtechnisch adäquat abzubilden ist schwierig bis unmöglich.
--- SaschaDördelmann