Not invented here Syndrom

Ich kenne ja eine Menge PHP Entwickler. Oder besser: Ich kenne eine Menge Softwareentwickler. Und von fast jedem habe ich bereits den folgenden Satz gehört „Die Bibliotheken, die existieren, können nicht das was wir brauchen, deswegen machen wir das lieber selbst“. Und natürlich habe ich diesen Satz auch schon aus meinem Mund gehört. Leider.

Aber wenn man mal ehrlich zu sich ist, dann ist diese Einstellung völlig daneben. Die meisten Probleme wurden bereits gelöst und da muss ich nicht das Rad neu erfinden. Ganz nett finde ich auch den englischen Ausdruck „don’t reinvent the squared wheel„, denn alles was ihr schreiben werdet, wird nie den Umfang erreichen, wie das Projekt, dass ihr abgelehnt habt. Besonders gerne werden hier Datenbank Schichten oder XML Parser neu erfunden. MVC Frameworks sind auch ganze vorne dabei.

Früher war ich auch der Meinung, dass mein ganz eigenes Framework, viele Probleme lösen kann, die andere nicht können. Es war garantiert viel besser als alles andere, was jemals erfunden wurde. Es war properitär und hatte genau einen Entwickler und einen Anwender. Jetzt dürft ihr raten wen. Den Nils. Ich weiss, war echt schwer. Hätte ich damals auf ein Standard Framework aufgesetzt, dann hätte ich ordentlich von der Community profitieren können. Die nutzbare Funktionalität, wäre erweitert worden, ohne dass ich etwas dazu tun müsste. Plugins wären geschrieben worden, Sicherheitslücken wären gefunden worden und und und. Aber nööö. Nils musste ja was eigenes schreiben. Das ist jetzt auch schon eine ganze Weile her und ich bin da ein wenig „reifer“ geworden, aber oft stehe ich trotzdem vor einem Problem und denke, dass ich das viel besser als alle anderen lösen kann und dann muss ich mir auf die Zunge beissen und mir eingestehen, das dem wohl doch nicht so ist.

Denkt immer dran, es gibt hunderte User, die sich zum Besipiel um die Klassen des Zend Frameworks kümmern. Wenn die eine Amazon Webservice Klasse basteln, dann machen sie nur dies. Diese Klasse wird dann von zig Leuten genutzt und man kann sicher sein, dass keine großen Bugs drinnen sind. Und auch wenn diese Klasse weiterentwickelt wird und zum Beispiel auf den Amazon Standard 12a3, den ich gerade erfunden habe, geupdatet wird, dann muss ich hier nichts mehr machen. Bei meiner properitären Lösung würde ich alles noch mal anpassen und durchdenken müssen.

Ok, es ist gerade 2 Uhr nachts als ich den Artikel verfasst habe – und ich glaube man merkt meine Müdigkeit – deswegen kommeich mal zum Ende. Was ich also sagen will. Überlegt euch gut, bevor ihr etwas bereits gelöstes neu erfindet. Es gibt bestimmt Fälle in dem dies notwendig ist. Ihr solltet aber trotzdem die Augen auf lassen, denn es kann der Zeitpunkt kommen, in dem eure Technologie überholt wird und dann solltet ihr versuchen auf das „bessere Pferd aufzuspringen“.

13 Comments

Wahre Worte! Es hat bei mir auch etwas gedauert bis ich genau das realisiert habe, mittlerweile setze ich voll und ganz auf das Zend Framework und bin damit mehr als zufrieden. Eine starke und große Community hinter einem Projekt ist und bleibt ein Vorteil den man alleine einfach nicht erreichen kann, auch nicht in einem größerem Team wie wir es hier sind.

Ich hab mir ein eigenes Framework geschrieben, einzig mal ein Mini-Caching System, das schöne 304 not modified Header rausgehauen hatte und die Response in 2 Schüben auslieferte (HTML Head Bereich und danach den Body-Bereich). Dadurch war das System super schnell, aber auch nicht gerade gut geschützt gegen Angriffe. Ich setze seit fast 2 Jahren das Zend Framework beruflich ein und bastel damit auch privat herum 😉 Einzig gegen Template Systeme wie Smarty hab ich was, aber das ist eine andere Geschichte …

Das Ganze kann sogar noch weiter gehen: 1 Entwickler, 1 Anwender, 1 Projekt, d.h. ich habe mal für ein neues Projekt gleich ein neues „Framework“ geschrieben, das dann nur in einem Projekt eingesetzt wurde. Es kam halt raus, dass es nicht gut skalierte. Beim nächsten Projekt habe ich dann ein neues „Framework“ geschrieben. Das wurde dann in 3 Projekten eingesetzt. Das war so um 1999/2000 herum.

Ich schreibe übrigens „Framework“, weil das Stück Software aus meinen Fingern diesen Namen eigentlich nicht verdient hatte… 😉

Manchmal macht es in meinen Augen schon Sinn, etwas selbst zu bauen – ein Framework wie das Zend Framework ist gut und schön, wird ständig durch neue Features erweitert…

Aber das bedeutet in den meisten Fällen auf unnötigen Overhead und manchmal gibt es ebene nichts wichtigeres als eine gute Performance. Da bin ich mit einer eigenen Lösung, die absichtlich nur auf genau das ausgelegt ist, was ich will, meist besser dran – eine gute Planung vorausgesetzt. 🙂

Ich setze auf eine gute Mischung.

Wie wahr, wie wahr. Vor allem, wenn dann doch mal jemand weiteres an das Projekt ran muss und dieser dann evtl. schon Erfahrung mit dem bereits eingesetzten System hat. Die Chancen, hier jemanden zu finden, der sich nur noch in die Businesslogik einarbeiten muss, aber nicht in Funktionsbibliotek/Framework steigen in diesem Fall nämlich deutlich.

Stimmt!

Ich gehe jetzt auch langsam dazu über immer mehr ein Framework zu nutzen, aber auch nur deswegen, weil ich mich jetzt bereit und in der Lage finde. Durch das jahrelange selbstprogrammieren von den verschiedensten Sachen habe ich mir ein sehr gutes und umfangreiches Wissen zum Thema Programmieren und für den Hintergrund einer Aufgabe, z.B. E-Mails empfangen und versenden – also zwangsweise auch den Aufbau von E-Mails, angehäuft. Zu dem ist die Erfahrung, die ich durch die Erstellung der einzelnen Klassen erhalten habe unersetzbar.

Kurz, mit meinem jetzigen Wissen fühle ich mich nicht nur in der Lage ein Framework zu benutzen, sondern es auch zu verstehen und ggf. zu Erweitern. Mit anderen Worten finde ich es nicht so verkehrt „erst einmal“ selbst ein eigenes Framework zu schreiben.

In allen anderen Punkten, z.B. auch Aktualität etc. stimme ich überein.

Auch wenn alle Argumente der Wahrheit entsprechen, möchte ich anmerken, dass du nur die wirtschaftliche Seite beleuchtet hast, denn es gibt auch noch andere Motive, gewisse Probleme abermals zu lösen:
1.) Spaß an der Entwicklung und der Herausforderung.
2.) Man kann sich durch eine Eigenentwicklung mit einem komplexen Thema vertraut machen.
3.) In einigen Fällen sind die vorhandenen Lösungen unpassend für ein Problem.
Während die ersten beiden Motive wirtschaftlich uninteressant sind, da man solche Projekte i.d.R. nicht weiterverfolgen wird, gibt es (für mich) durchaus Fälle, in denen die Lösungen nicht passend für das Problem sind. Dieser Fall tritt vor allem dann auf, wenn die vorhandenen Lösungen zu groß für mein Problem sind und man sich fühlt, als würde man mit Kanonen auf Spatzen schießen. Beispiel: Für kleine Homepages verwende ich keine „Business-Frameworks“, sondern mein Vier-Klassen-„Miniframework“, mit dem ich nur das habe, was ich wirklich benötige.
Nichtsdestotrotz sollten vor allem Bibliotheken, die sich an Standards orientieren, wiederverwendet werden aus den bereits im Artikel genannten Gründen.

@Blackflash das ist etwas kurzsichtig. Was ist wenn du morgen deine Twitter Nachrichten einbinden willst, übermorgen willst du dann noch eine Galerie aus Flickr Bildern haben.

Grade die Schlachtschiffe unter den Frameworks sollte man so gut beherrschen, so das man jede Art von Webseite/Webapp damit erstellen kann. Die Anforderungen von Morgen machen es sonnst nötig.

Naja, teilweise ist es ja richtig was hier steht, aber wenn alle so denken würden, dann hätten wir ein einziges Framework. Da es ja dann schon ein Framework gibt, müsste ja keiner ein neues entwickeln. Wir hätten also das „Windows Framework“ … keiner mag es, alle meckern und trotzdem nutzt es jeder. Wie Blackflash schon geschrieben hat, es kann und soll auch spaß machen so eine Geschichte aufzuziehen und der Lernfaktor sollte hierbei nicht unterschätzt werden.

just my 2 cents

@Blackfish: Ich gebe dir vollkommen recht. Punkt 1 und 2 sind auch per mir immer noch an der Tagesordnung, aber eher im privaten Umfeld. Das Kanonen auf Spatzen schießen Problem sehe ich auch so, aber gerade bei dieser Framework Geschichte gibt es ja schon jede Menge Microframeworks, die ich nutzen kann. Verstehe aber deinen Ansatz nur zu gut und in vielen Fällen hast du wohl auch Recht.
Kommt wohl immer darauf an, wo der Fokus des eigentlichen Projektes liegt. Hilfsmittel sollte man aber so weit es geht woanders „einkaufen“.

@Ben Rexin: Bereitet man sich hingegen auf alle möglichen Fälle vor, von denen die meisten mit an Sicherheit grenzender Wahrscheinlichkeit nicht eintreten, dann investiert man eindeutig zu viel Energie. Fehlt hingegen etwas, lässt es sich leicht nachrüsten, denn für Twitter oder Flickr gibt es bestimmt genügend Bibliotheken, die ich in mein Projekt einbinden und verwenden kann. Es geht ausdrücklich nicht darum, alles selbst zu entwickeln, sondern bei der Planung des Projekts zu beachten, welchen Umfang das spätere Projekt haben wird. Bei eigenen Projekten, die man nebenbei durchgeführt, ist die Planung einfach. Wie es bei Projekten in deinem Umfeld aussieht, kann ich nicht sagen. Dort mag deine Behauptung durchaus Bestand haben.

Die gesamte Argumentation stimmt natürlich, wenn man mit Webprogrammierung seine Brötchen verdient, schließlich geht es dabei um gnadenlose Optimierung und außerdem hat man genügend Zeit, sich mit der Materie zu beschäftigen und somit auch in großen Frameworks fit zu sein. Wenn man allerdings nebenbei eine (kleine) Webapplikation entwickeln will, dann finde ich das Einlesen in etablierte Frameworks zu aufwändig und schaue mir ein Miniframework an, das ich in maximal einer halben Stunde verstanden habe.

Aber die Wahl von Frameworks hat sehr viel mit Geschmackssache zu tun, darüber kann man nicht sinnvoll diskutieren. 🙂

Hier wurden ja schon einige sinnvolle Argumente für beide Seiten genannt.
Ich will mal grad ein kleines Beispiel zum Thema anbringen:

Ich brauchte ein JS-Script, welches per Ajax die Blätter eines Baums nachlädt, wenn der Nutzer auf die Knoten klickt. Sowohl Knoten als auch Blätter sind allerdings Tabellenzeilen, welche aus mehreren Werten bestehen. Daten kommen aus einem PHP-Array, wie sie nach JS kommen war mir egal: json, xml, csv, was auch immer das Script haben will.

Ich war mir sicher dass es genau das kostenlos irgendwo schon gibt.
Ich habe einen Arbeitstag damit verbracht, es zu suchen. Ich habe kostenpflichtige (proprietäre) Lösungen gefunden. Ich habe kostenlose Lösungen gefunden, die aber nicht mit Tabellenzeilen umgehen konnten. Ich habe versucht abzuschätzen, wie leicht sich diese erweitern und anpassen lassen. Ich habe versucht eine aussichtsreiche Lösung anzupassen. Es ließ sich nicht sauber machen, ohne alles über den Haufen zu werfen.
Am nächsten Tag habe ich es selbst neugeschrieben. Es hat mich einen halben Arbeitstag gekostet. Es ist nicht sonderlich schön geworden, weil es mein erstes richtiges Ajax-Projekt war, aber ich habe viel gelernt.

Es kommt immer drauf an 😉