Open Source? Scheissegal

Achim Schäfer
20.07.2012 17:10:41 #

Hi Hannes,
weitgehend gebe ich Dir recht, mir ist es auch relativ egal, ob Open Source oder nicht und die Aufforderungen aus der "Szene", dann könne man nachschauen/nachvollziehen, was das Tool/die Lib macht und man könne Fehler ausbügeln usw., k.... mich nur noch an, sind sie in der Regel doch nur Ausrede für fehlende Dokumentation!

Aber in zwei Punkten muss ich Dir HEFTIG widersprechen:

"offene Standards" sind IMHO extrem wichtig: ohne solche würden wir bei jeder Lampe nachschauen müssen, von welchem Hersteller aus welcher Serie aus welchem Jahr... So haben wir "nur" noch die Wahl zwischen vielleicht einem Dutzend verschiedener Sockel... Und wir hätten auch keinen Unicode, sondern jeder würde mit irgendeiner eigenen Kreation ...

"Dein Code ist gut- solange er läuft" - SEHR kurzfristige Sichtweise auf den ersten Vorführtermin beim Kunden, spätestens in der Woche vor der Endabnahme rächt sich diese Ansicht 100%ig....

ein schönes Wochenende aus Nürnberg ins Grenzgebiet wünscht Dir
Achim

Hannes
20.07.2012 17:30:50 #

Guter Code wird automatisch zum schlechten Code wenn er nicht läuft, oder jemand Dritter ihn modifizieren muss. Aber das ist nicht der Kern
Die Aussagen zu Standards kann man in der Tat differenzieren. Standards sind an vielen Stellen wichtig und haben große Fortschritte ermöglicht. Sie müssen es aber nicht! Für die meisten meiner Entwickleraufgaben ist es auch ohne Belang obs ein Standard ist. Da ist eher von belang wenn es ein Standard ist, wie er implementiert ist. Ich kann sagen alleine bei einem popligen RFC Pop3 kannste in der Praxis was erleben. Dann spielt noch ein entscheidende Rolle, wessen Standard (OMG, ISO, RFC, W3C ect)

Rateaufgabe Standard oder kein Standard
SOAP
JSON
REST
TIFF
Corba
Java
C++ (der ist leicht
SQL (PSQL, TSQL)
JQuery

Golo Roden
20.07.2012 18:02:31 #

Ganz ehrlich: Lange nicht mehr so einen Mist gelesen.

Der Entwickler profitiert nicht von offenen Standards? WTF? Sorry, da fällt mir nix mehr zu ein. Und keiner verlangt, dass Du den Sourcecode liest oder dran mitwirkst. Aber es ist wichtig, dass es die Möglichkeit gibt. Nicht für Dich, aber für viele andere. Opensource ist ein gutes Konzept, und durchaus tragfähig. Wer Open Source per se schlecht heiß und offene Standards verteufelt, hat meines Erachtens nicht verstanden, wie IT funktioniert.

Insofern: #epicfail

Golo Roden
20.07.2012 18:03:31 #

PS: Dieses Blog (BlogEngine.NET) ist Open Source ... ist das jetzt auch böse ?

Hannes Preishuber
20.07.2012 18:13:49 #

zum Blog: Ich würde Geld dafür zahlen, wenn das Ding fehlerfrei wäre, zwei Bugs habe ich selber gefixt- zu mehr keine Lust

@Golo: Kein schlecht- kein Teufel. Für mich schlicht Scheissegal (zugebenermaßen überspitzt)

Aber um mal dein Argument aufzugreifen "IT nicht verstanden"-das ist der Punkt, den ich nicht persönlich nehme. Nur weil ich (oder jemand) etwas nicht super findet, hat er nichts verstanden. Das ist wertend, ich würde meinen stark negativ wertend. Genau das will ich ausdrücken. Ich bin gut (und alle werten Mitleser, samt Golo sind gut) auch wenn andere Dinge wichtig sind. Die Welt der Entwickler und IT ist wesentlich größer als OOP das im Ansatz beschreiben könnte. (Programmier mal nen Microcontroller mit Assembler)

( PS die Wertung meiner Meinung als Mist verzeihe ich gerne, in Wertschätzung unserer langjährigen Bekanntschaft)

Gordon Breuer
20.07.2012 18:55:38 #

Golo vs. Hannes - Fight!

Na gut, dann halt ernsthaft ...
Ich behaupte mal, dass Hannes sowohl Überschrift als auch Text absichtlich so provokant, vielleicht sogar etwas überspitzt geschrieben hat. Zunächst einmal aber die Anmerkung meinerseits, dass ich ähnliche Vorbehalte wie Achim habe: Standards - unabhängig von der IT - sind wichtig. Nur durch sie sind heute alle Transportcontainer genormt und können so automatisiert und vereinfacht abgefertigt und transportiert werden. Die Glühbirne ist ein weiteres Beispiel. Werden wir jedoch ein wenig konkreter, und meinen nur "Standards in der IT" sieht es ein wenig anders aus. Auch hier haben wir Standards, aber offenbar wird sich bei der Implementation nicht immer so genau an diese Standards gehalten. Noch einen Schritt weitergehend stellt sich die Frage, wer überhaupt einen weltweit gültigen IT-Standard beschliessen können sollte. Und die Frage, was überhaupt ein echter, definierter Standard ist und wie dieser aussieht, ist selten ganz eindeutig und auf die Schnelle zu sagen.

Das eigentliche "Kampfthema" (ich liebe solche Worte!) ist aber vermutlich dann doch OpenSource. Jetzt mag man davon halten, was man möchte. Aber der Weisheit letzter Schluss ist sie sicher nicht, sonst hätte sie sich längst durchgesetzt. Der Trend wird mal stärker, mal schwächer - genau so wie OpenSource ansich Stärken und Schwächen hat.
Hin und wieder studiere ich ganz gezielt den Quellcode von interessanten Projekten, bsp auf CodePlex oder auch GitHub. Es ist manchmal faszinierend, wie völlig anders manche Leute etwas realisieren und programmieren als man es selbst gemacht hätte. Aber nur durch diese ständige Selbst-Evaluierung kann ich auch verhindern, meine eigenen Prinzipien und Denkstrukturen als das non-plus-ultra zu sehen. Denn es gibt so viele schlaue Köpfe da draußen, die es anders machen - warum so, und nicht so? Bücher & co. sind da nur ein erster aber sehr einseitiger Schritt.

Gar nicht gut finde ich es, wenn die Entwickler von OpenSource eine miese Usability auf selbige schieben. "Es kann ja jeder mitarbeiten" ist nur eine Umschreibung für "Hab keine Lust, solls doch ein anderer machen - ich verstehe es auch so!". Es gibt auch positive Gegenbeispiele, aber mangelnde Dokumentation und unsaubere Schnittstellen sind leider seit Jahren die Regel. Aber nicht jeder, der ein OpenSource-Projekt nutzt hat auch gleichzeitig die Zeit, erst mal den ganzen Code zu lesen und auch noch zu verstehen, nur um rauszufinden wie er benutzt wird.
Vieles gäbe es heute in dieser Form ohne OpenSource nicht, und ich halte es grundsätzlich für eine gute Sache. Aber oft geht es mir wie Hannes: Ich möchte eine bestimmte Funktionalität in Form einer fertigen Library einsetzen und es ist mir dabei völlig "scheissegal", ob ich mir den Quellcode davon nun ansehen kann oder ob ich eine fertig kompilierte .dll-Datei habe. Immer? Nein, es gibt eine Besonderheit an die oft nicht gedacht wird: Die Lizensierung und das Enterprise-Umfeld. Es gibt eine völlig unüberschaubare Anzahl an OpenSource-Lizenzen, und die meisten davon sind nur schwer verständliches juristisches Kauderwelsch, zumeist auch noch auf englisch. Natürlich weiss ich grob, was ich bei einer Apache-Lizenz darf und was nicht, oder bei einer GPL.... wobei, halt - GPL2 oder GPL3 ... oder gab es noch mehr Versionen? Und welche hat das Projekt gerade - oder beim nächsten Update? Gerade Unternehmen tun sich oft schwer damit, OpenSource-Projekte zu verwenden, weil zum einen der Support ungewiss ist (auch hier gibt es wieder Ausnahmen) oder weil die Verwendung in ihren firmeneigenen closed-source Systemen einfach problematisch wäre. Von daher darf es mir als Consultant nicht immer "scheissegal" sein, aber oft geht es mir hier wie Hannes - und ob OSS oder nicht tangiert mich nur peripher ..

Achim Schäfer
20.07.2012 21:51:32 #

Noch ein Nachschlag zu "Open Source":

- vorweg: ich bin kein "gelernter" Informatiker, sondern habe mal Nachrichtentechnik an der TU München studiert und lange Jahre Hard- und Firmware-Entwicklung (Telemetrie u.ä.) gemacht -

Ich bin absolut kein Feind von Open Source, mich stört nur (abstoßen wäre sogar der bessere Ausdruck) die Religion, die da draus von vielen gemacht wird. In meinen "Hardware-Tagen" war es absolut üblich, dass bei gekauften Baugruppen nicht nur eine Schnittstellenbeschreibung dabei war, sondern natürlich auch komplette Schaltbilder (das Gegenstück zum Source Code) und bei µC-basierten Dingen zumindest der Quellcode des Monitor- oder Bootloader-Programms. Und selbst in der Unterhaltungselektronik: man machte die Rückwand auf und da war in einer "Schublade" das komplette Schaltbild samt Meßpunkten und zugehörigen Werten. Und Jede Firma hatte ihre Hauszeitschrift für Werkstätten usw., in der nicht nur Geräte vorgestellt wurden, sondern auch bestimmte neue Schaltungsdetails z.B. genau beschrieben waren.   Natürlich hat man angeschaut, was die Konkurrenz so baute (und warum). Man lernte sozusagen gegenseitig, jeder profitierte... Selbst für den IBM PC XT und AT gab es noch gegen Aufpreis die "Technical Reference" mit Schaltbildern und Assembler-Quellcode des BIOS!

Erst als die Produkte sich immer ähnlicher wurden (weil man nur das Referenzdesign des Chiplieferanten farblich anpasste...) begann diese Geheimniskrämerei auf der einen Seite und die "Religiosität" auf der anderen...

Norbert Eder
20.07.2012 23:02:57 #

Was genau hat denn die Quintessenz deiner Aussage mit Open Source zu tun? Eigentlich gar nichts. Einfache Werkzeuge, gepongt. Programmierkonzepte, gepongt. Steuerelemente, ja. Kunden die zahlen, natürlich brauchen wir sie! Aber viele Dinge wären ohne Open Source heute bei weitem wesentlich schlechter als sie sind. Gewisse Standards hätten sich nicht durchgesetzt.

"Offene Standards" braucht keiner. Ja. Der, der sein Netzwerkkabel abhängt, seinen WLAN-Router abschaltet, keine USB-Geräte verwendet etc. DER braucht keine offenen Standards. Auf offene Standards treffen wir jeden Tag, unabhängig der Softwareentwicklung oder gleich der ganzen IT. Einfach die Augen auf, sie lauern überall. Eine derartige Aussage zeugt von extremer Kurzsichtigkeit, was ich dir nicht zutraue. Eher geht's hier wohl um die Kontroverse und die Aufmerksamkeit an sich. Ist ja gelungen.

Abgesehen davon: Jemand, der Software entwickelt weil er glaubt in dieser Branche die große Kohle zu machen, dem bringt ein Step-by-step Konzept Nüsse. Siehe MVVM. Setzt doch jeder ein, weils hipp ist/war. Verstanden hat's? Kaum jemand. Ein Software-Entwickler hat seine Hausaufgaben zu machen. Die Basis-Patterns (siehe at least Gang of Four) MÜSSEN bekannt sein. Er muss mit Tests umgehen können etc.

"Was brauchen 99% der Entwickler?": Mal ein paar Wochen keine Suchmaschine, ein paar ordentliche Bücher, ein paar Gespräche mit erfahrenen Entwicklern und eine Herausforderung an der sie wachsen können.

Hannes Preishuber
21.07.2012 11:18:43 #

Es geht darum, das die Majorität der Entwickler sehr erfolgreich fernab von Standards und Open Source agiert und sich deswegen, keine Sekunde schlecht fühlen sollte. Mich stört das andauernde bashing der "nicht wahren" Entwickler. Wenn 1% voll an Standards und Open Source hängen (oder meinetwegen auch 5%) ist das auch OK.

Dann gibt es zwei Handlungsstränge, Einer ist Standards und der andere Open Source. Ich will das Thema Standards hier weiter aufgreifen. Standards sind wichtig, aber nicht alles.
>"Offene Standards" braucht keiner. Ja. Der, der sein Netzwerkkabel abhängt, seinen WLAN-Router abschaltet, keine USB-Geräte verwendet etc. DER braucht keine offenen Standards. <

TCP/IP keine Diskussion, http gegessen. Standards, aber es gab Alternativen teilweise auch Standard.
Wlan da gibt's viele nette Standards. Kauf dir in USA ein 802.11b/g Standard Gerät und hängs in Europa an Kanal 12 oder 13. Nüsse. USB- hat ja jedes iPhone und Ipad (wer hat am meisten Erfolg indem er auf offen und Standard pfeift?)

Wer bitte, und das ist die Business Schicht der Frage, ist heute Market leader weil er führend in der Implementierung von Standards ist mit Open Source?

Zurück zum zentralen Punkt meiner Aussage. Nur weil es ein Standard ist, ist die Lösung nicht zwingend besser. Zwingend weniger Innovativ, zwingend weniger aufs  Problem fokusiert.

Hannes Preishuber
21.07.2012 11:42:11 #

@Achim auch ich bin Nachrichtentechniker und kann mich gut erinnern, das in der Tat bei einem Philips Fernseher der Schaltplan innen mitgeliefert wurde. Das ist lange her.
In der Nachrichtentechnik ist in Anbetracht der Vielzahl an Anbietern und Märkte der Standard der einzig gangbare Weg erfolgreich und kostengünstig im Markt bestehen zu können. Siemens war mit seinen Hicom Dingern der letzte der das anders versucht hat.

Kurt
21.07.2012 22:06:44 #

Er beschreibt ziemlich genau die typische Kultur die bei typischen enterprise Firmen die MS Technologien benutzen zu finden ist. Es ist nicht das die Entwickler schlecht sind, sondern das Management orientiert sich um Angst und vertraut die Entwickler nicht. Dann kommt viele Standards, Regeln, und Beschränkungen. Die Entwickler haben nicht die Freiheit fortgeschrittene Fähigkeiten zu entwickeln oder in der Firma zu benutzen, und bleiben also unmotiviert.

Ganz oft haben Management Angst das es zu schwer wäre Entwickler zu finden die z.B. TDD oder nicht-MS-Tools können, also werden sie einfach verboten.  Oder sie haben Angst das wenn Entwickler werden "ganz wild" anfangen irgendwelche Arten von Tests zu schreiben, oder mein Gott, selbst "Design Entscheidungen" zu treffen, ohne den Architekt zu lassen solche "schwierige Sachen" zu tun (als ob Entwicklung etwas anders wäre als Design Entscheidungen zu treffen), oder vielleicht eine DB Schema selbst anpassen zu dürfen (nur ein DBA versteht natürlich wie das geht ohne das Performance kaputt zu machen),  dann wird alles irgendwie Chaos. Sie verstehen nicht das Entwickler sind klug und können neue Sachen lernen.

Warum soll ein Entwickler was lernen, oder Interesse auf Open Source haben, oder in der Community teilnehmen, wenn es bringt in der Arbeit nichts? Weil Management hat alles so fest definiert, wie alles sein wird. Oder weil ein Architekt hat schon ein Design im Voraus gemacht wo die Entwickler nur bunty-klicky, Kopie-Pasta machen dürfen.

Naja es ändert sich langsam. Diese Kultur geht nur ein paar Jahre dann gibt es so viele technische Debt das es geht nicht mehr. Schlechte Managers und Architekten werden ausgelacht und ignoriert, und Entwickler werden einfach die Freiheit greifen alles richtig zu machen.

Erich Eichinger
22.07.2012 03:05:46 #

... und die Erde ist flach, weil alles andere uebersteigt meinen Horizont.

Fehlerhafte Open Source Bibliotheken? Ja, gibt es. Genauso viele Bugs oder Inkonsistenzen gibt es in der .NET BCL (nur als Beispiel) und in anderen kommerziellen closed-source Libraries. Und wenn du nie das Beduerfnis verspuert hast, in den Source Code einer Bibliothek oder eines Frameworks, dass du gerade benutzt, hineinzusehen, dann programmierst du wohl nicht viel. Andere Sprachen und Plattformen sind zu muehsam zu lernen? Du koenntest viel von ihnen lernen.

Was Open Source wirklich ist? Es ist eine Einstellung. Es geht darum, selbst besseren Code zu schreiben und sich mit anderen auszutauschen. Saemtliche Codebeispiele, die du so zusammengooglest, sind Open Source.

Dein Code ist gut, nur weil er laeuft? Das funktioniert, wenn du ein kleines Hilfstool fuer die Sekretaerin "bastelst" und deinen Kunden nie wieder in die Augen sehen musst. Kunden, die zahlen? Ja genau ein mal. Das zweite Mal werden sie wohl zu jemandem anderen gehen.

Ich habe es satt, wenn Leute mit deiner Einstellung in Bewerbungsgespraechen meine Zeit verschwenden. Genau solche Point&Klick Entwickler haben VB (und die gesamte Entwicklergemeinde) in so zweifelhaften Ruf gebracht. Ich finde es schockierend, wenn du dich damit auch noch bruestest, ganz zu schweigen davon, dass du offenbar auch noch Unschuldige entsprechend schulst.

Was brauchen 99% der Entwickler? Gute Vorbilder. Du bist keines.

Hannes Preishuber
22.07.2012 12:04:23 #

Danke Erich, das Du Dich hier offen und persönlich äußerst und nicht einfach 1 Sternchen anonym click machst.
Inhaltlich tu ich mir schwer die Argumente zu finden, wenn man den Teil weg lässt der sich mit angriffen auf meine Person beschäftigt.
Interessant finde ich "Was Open Source wirklich ist? Es ist eine Einstellung. Es geht darum, selbst besseren Code zu schreiben und sich mit anderen auszutauschen."

Das hatte ich bisher nicht gesehen. Mein Eindruck ist, statt der perfekten Lösung die Bauanleitung, ala IKEA zu bekommen. (ich hasse Regale zusammenbauen)
Für Dich ist Open Source ein Einstellung, vielleicht sogar ein Kult oder gar eine Religion. Jedenfalls mit scharfer Abgrenzung zu all denen die VB zusammen clicken machen und denen die nicht die reine Lehre vertreten. Das ist OK.
Nicht OK finde ich, Menschen die nicht deine Meinung oder Deine Werte teilen zu diffamieren, zu polemisieren, zu diskreditieren. Das zeugt nicht von Aufklärung, eher von deiner zitierten Scheibe.
Resume für mich: Dein Post erklärt die aus meiner Sicht extremen Reaktionen ( ich lese auch Twitter),. Immerhin habe ich Die Glaubensbezeugung als Scheissegal bewertet.

Ich wünsche mir bei den negativ Statements, das sich der Blog Leser einmal mit den Inhaltlichen Aussagen auseinander setzt. Kein verteufeln, keine Absolutaussagen, meine Meinung.

Um mein Statement zu ergänzen. Für mind 90% ( ich werde vorsichtiger) ist Softwareentwicklung ein Job und das ist OK.

Erich Eichinger
22.07.2012 13:37:13 #

Mitnichten greife ich dich persoenlich an. Kann ich und will ich nicht, ich kenne dich nicht. Und so, wie es aussieht, werden sich unsere Wege auch so bald nicht kreuzen.

Was die Argumente angeht, moechtest du meine Antwort vielleicht noch einmal lesen. Qualitaetsbewusstsein ist fuer mich weder eine Religion noch Kult, es ist fuer mich wesentlicher Teil einer professionellen Grundhaltung. Ich kenne auch exzellente VB Programmierer (war selber mal einer). Ich verteufle keine Heraetiker, ich verurteile den Mangel an Qualitaetsbewusstsein und die ablehnende Haltung zur Selbstentwicklung, die aus deinem Post schreit.

Ich bin zutiefst dankbar, dass die meisten Aerzte und Krankenpfleger eine weitaus professionellere Einstellung haben als du sie in deinem obigen Post vertrittst.

Hannes Preishuber
22.07.2012 14:07:32 #

>Qualitaetsbewusstsein ist fuer mich weder eine Religion noch Kult, es ist fuer mich wesentlicher Teil einer professionellen Grundhaltung.<
Da passt kein Blatt Papier zwischen Deinem und meinem Anspruch

>ich verurteile den Mangel an Qualitaetsbewusstsein und die ablehnende Haltung zur Selbstentwicklung, die aus deinem Post schreit<
Das habe ich so nicht geschrieben und Deine Interpretation ist falsch.

Menschen die sich kontinuerlich weiter entwicklen und selbst hinterfragen haben meine größte Hochachtung. Genau wie Menschen die Ihre Freizeit dafür aufwenden. Das fordert und fördert ppedv von seinen Mitarbeitern.

Open Source hat damit allerdings mit Qualität wenig zu tun und auch nicht mit dem der Grundeinstellung dazu. Viele der OS Entwickler sind ganz normale Entwickler die ua von IBM und co dafür bezahlt werden um die Business Ziele zu verfolgen. Wenn das Budget alle ist, dann hat man den Schource (meine Kreation) und darf sich selbst drum kümmern.

Für mich ein gutes Beispiel ist die Callisto Lib (https://nuget.org/packages/Callisto) von Tim Heuer. Ein Microsoftie den ich schon seit Jahren kenne und schätze.
Darin wird die u.a. die fehlende Flyout Funktion ( die es mit JavaScript) von Windows 8. XAML, als Open Source nachgebildet. Viel besser wäre es, Microsoft hätte seinen Job gemacht. Ich kann auch niemanden empfehlen, callisto im Produktiv Einsatz zu verwenden. Wer weis, was morgen damit ist? Was sind die Kosten der Verwendung über die Lebensdauer (TCO)? Welche Human Resources brauche ich, um so eine Lib pflegen zu können (das sind in der Regel die Top Level Devs)?

Stephan
23.07.2012 03:14:16 #

Hallo,

Manche Deiner Gedanken kann ich gut nachvollziehen, aber die Folgerungen daraus werfen nicht unbedingt ein gutes Licht auf jemanden der andere Entwickler ausbildet.

1. Open Source

Gute Software wird nicht dadurch schlecht, dass sie Open Source ist sondern ...
Wenn sie fehlerhaft ist
Wenn sie schlecht dokumentiert ist
Wenn sie unsauber programmiert ist (was ich jetzt bewusst "dehnbar" formuliert habe)

Viele OS Pakete haben diesbezüglich Mängel, aber d.h. nicht das kommerzielle Software nicht dieselben hat.

Der größte Vorteil von kommerzieller Software ist ein guter professioneller Support, bei OS ist man hier auf die Hilfe der Community angewiesen ... da weiß man nicht unbedingt was einem erwartet.
Es gibt aber auch OS Projekte zu denen kommerzieller Support angeboten wird ... geht also auch ...

Wir haben z.B. sehr gute Erfahrungen mit kommerziellen Komponenten von DevExpress und Telerik gemacht.
Beide liefern den Source Ihrer Komponenten mit, das wäre Deiner Meinung nach ja sinnlos ...
Ich will mit Sicherheit nichts darin ändern, aber es gehört zur Investitionssicherheit dazu, das ich es könnte, wenn ich müsste, z.B. wenn es diese Firmen morgen nicht mehr gäbe.

2. Entwickler brauchen "Programmierkonzepte die Step by Step zum Erfolg führen"
Dann nimm doch 4GL Tools, die bieten das schon seit Jahren
Du erzeugst dann nach Schema F seitenlangen Code Step by Step ...
Hirn bitte am Eingang abgeben - nicht nachdenken, man könnte ja von der Norm abweichen ...
Sorry, das erinnert mich mehr an Tiertrainer als an eine Entwicklerschulung

3. Wechselnde Frameworks/API
Als Entwickler sehe ich es als meine Aufgabe an über meinen Tellerrand hinauszuschauen.
Wenn es da etwas gibt, was mir meine Arbeit wesentlich vereinfacht oder evtl. gar dem Anwender der Software nützt, dann sollte ich mich damit auseinander setzen.
Wenn ich mich dabei nur von irgendwelchen "Hypes" leiten lasse bin ich natürlich selber schuld.

4 . Du bist gut, Dein Code ist gut- solange er läuft
Sorry, aber das ist tödlich - auch mit Smilie!
So gut wie jedes Programm muss während seiner Lebenszeit geändert werden.
Ändere mal Code der aussieht, wie wenn er durch einen Obfuscator gelaufen ist ...
Es ist schön wenn ein Programm läuft, doch oft ist es wichtiger, wenn Dir ein Programm sagt,
warum es heute nicht läuft ...

Hannes Preishuber
23.07.2012 09:46:19 #

@Stephan, danke für den ausführlichen Beitrag. Da es in der Länge der Diskussion schwierig ist, die Aussagen im richtigen Kontext zu bringen, meine Aussagen
1) Open Source ist nicht schlecht oder gut, sondern ich brauche keinen Quellcode von z.b. EF . Wenn ein Toolhersteller seinen Source Code mitliefert macht das das Tool sicher nicht schlechter. Ich hätte zwar bedenken wie man das geistige Eigentum schützt, aber das ist das Problem von DevExpress oder Telerik.
2) im Nachgang betrachtet ist es zu anmaßend zu sagen, was jemand Dritter braucht. Insofern revidiere ich meine Aussage in: Es zeigt sich in der Lernkurve meiner Schulungsteilnehmer, das Konzepte die Step by Step zum Ergebnis führen schneller verstanden und erfolgreich nachvollzogen werden können.
3) die Anzahl der Möglichkeiten und die daraus resultierenden langjährigen Konsequenzen übersteigen aktuell die verfügbaren Arbeitsstunden. Von fundamentalen Entscheidungen wie HMTL5 vs XAML hin zu spezifischen implementierungsdetails des Service Layers. Sehr schwierig zu verstehen und umzusetzen. In der Praxis wird dann, sobald ein Zweig verstanden wurde, dieser universell eingesetzt. Die Kunden sind sehr misstrauisch geworden, seit Silverlight ( und damit auch WPF) so sang und klanglos ins Eck gestellt wurden. Da würde auch kein Source Code von SL5 helfen.
4) Ausgehend von meiner These, das die meisten der Entwickler ganz froh sind, wenn der Kunde am Ende zahlt. Wenn man dazu die Leute zählt die C++, Windows Embeded, Assembler, Foxpro, VB 6, VBA usw Code schreiben, dann ergibt sich ein hoher Prozentsatz von Menschen die den Clean Code Paradigma nichts abgewinnen können. Ich halte es nicht sinnvoll im Sinne einer kontinuierlichen Verbesserung diese per Fingerzeig an den Rand zu stellen. Vor allem wenn der Finger von einer selbst ernannten Elite kommt.
vgl
www.welt.de/.../Freikletterer-am-Abgrund.html
10 Jahre lang wurde C++ Entwicklern erzählt, wie sie Ihren Code nach .NET portieren können. 10 Jahre nichts Neues zu C++ aus Redmond. ppedv hat dies erkannt und mit der ADC++ (www.adcpp.de) vor 2 Jahren ein Neues Event Format erfunden und den Entwicklern gesagt, das was Ihr tut ist gut. Ihr müsst nichts migrieren (witzigerweise hat die Entwicklung den C++ Realitätsverweigerern nachträglich Recht gegeben).
Wir als ppedv respektieren jeden Entwickler. Wir werden jedem Entwickler helfen seine Probleme zu lösen und seine Fragen zu beantworten. ppedv wird aber nicht erziehen und bevormunden. Was du tust geschieht in deiner Verantwortung und solange es funktioniert, solange dein Code fehlerfrei läuft, solange ist es gut. Überflüssig hinzuzufügen, das es immer etwas zu verbessern gibt.

Robert
23.07.2012 16:29:37 #

Im Gegensatz zu den meisten Kommentaren gebe ich dir bei zwei Kernaussagen Recht.

1. Die überwiegende Auffassung, wenn man etwas Open-Source macht, ist man einfach "cool", ist einfach lächerlich.
--> Die "Religiösität" von Open-Source wird übertrieben und überbewertet.
Ich finde es gut, dass du das mal geschrieben hast. Es ist immer wieder ein flaches Argument, dass sich alle Entwickler ja immer den Code anschauen und verbessern können, sodass alles dadurch toller, sicherer und besser wird. Ganz im Gegenteil. Ich glaube, dass Schwachstellen so noch häufiger ausgenutzt werden, anstatt, dass sie verbessert werden. Das ist z.B. bei den PHP-Foren, Blogs, usw. so, dass man damit eine riesige Zielgruppe erreicht, und es dann viel rentabler ist.

2. "Yea - man kann sich ja somit seine Lib selber kompilieren - ultracool".
(Vorausgesetzt man schafft es erst einmal, das Projekt zum Laufen zu kriegen.)
--> Neue Frameworks, die einen hippen Eindruck machen, Sachen aber unnötigerweise noch komplizierter lösen als vorher, sind ein Rückschritt.
Das ist z.B. in der Java-Gemeinde noch viel schlimmer. Jede Kleinigkeit ist da ein eigenes Framework mit einem schnittigen Namen. Wir verwenden ja gerade .NET, weil man Sachen schnell, produktiv und einfach lösen kann. Dass das ein Großteil gerne quick & dirty macht, wird durch wechselnde Frameworks auch nicht besser. Mit WinRT gibt es aber teilweise auch wieder einen Trend in die falsche Richtung.

Aber: Mit deinem Folgebeitrag über die Bloganalyse und die öffentliche Bloßstellung machst du dich ja sehr unbeliebt. Da wird dein Blog in Zukunft bestimmt öfters besucht und kommentiert als bisher...

Hannes Preishuber
23.07.2012 16:46:15 #

neue Argumente pro EF und Open Source

thedatafarm.com/.../

Erich Eichinger
24.07.2012 01:07:27 #

Ich schlage vor, dass jeder hier Stephan's Post oben mindestens 3x liest. Wenn es dann immer noch offene Fragen gibt, bin ich gerne bereit, sie zu beantworten. Ergaenzend allerdings noch ein paar Anmerkungen:

1) Open Source != gratis
Ein weit verbreiteter Irrtum - Open Source bedeutet lediglich, dass der Source Code eines Tools, einer Bibliothek oder eines Frameworks frei zugaenglich ist. Nicht mehr, nicht weniger

2) Schlechte Qualitaet
Wenn jemand schlechte Closed Source Software schreibt, wird er verhungern
Wenn jemand schlechte Open Source Software schreibt, dann kann er aus der Kritik wenigstens lernen

Wenn jemand schlechte Closed Source Software verwendet, dann hat er seine professionelle Pflicht zur ordentlichen Due Dilligence nicht gemacht
Wenn jemand schlechte Open Source Software verwendet, dann kann er wenigstens die groebsten Schnitzer selbst beheben wenn noetig (was ihn aber nicht von Fahrlaessigkeit 1ten Grades freispricht)

Wenn jemand gute Closed Source Software schreibt, dann kann er damit Geld verdienen
Wenn jemand gute Open Source Software schreibt, dann kann er damit Geld verdienen
Wenn jemand gute Closed Source Software verwendet, dann ist er gut dran, im Fehlerfall aber immer noch auf den Hersteller und seinen Support angewiesen
Wenn jemand gute Open Source Software verwendet, dann ist er gut dran und kann im Fehlerfall selbst dass Problem zumindest notduerftig beheben, bis der in den meisten Faellen vorhandene kommerzielle Support das Problem offiziell beheben kann.

3) Selber kompilieren
Kein Mensch verlangt von dir, dass du den Source Code selber kompilieren musst (Ich empfehle es allerdings, weil es erste Regel einer gut gepflegten Software ist, dass ein Clean Checkout problemlos kompiliert) Open Source ist ein Business Modell wie viele andere auch, mit dem Vorteil der Investitionssicherheit, dass du auch nachdem der Hersteller Konkurs angemeldet hat notwendige Aenderungen an der Bibliothek machen kannst.

4) Clean Code ist nur fuer eine .NET Elite
Robert Martin hat seine Artikel zu SOLID Prinzipien erstmals im Jahr 1996 im C++ Report veroeffentlicht. Zu sagen, dass ein "hoher Prozentsatz von Menschen die den Clean Code Paradigma nichts abgewinnen können" existiert, weil es C++ et al Entwickler an den Rand stellt, ist also - gelinde gesagt - uninformiert. Zumal es sich dabei um Prinzipien handelt, die Platform- & Sprachunabhaengig sind.

5) Architektur "schwierig umzusetzen"
Architektur zerlegt ein komplexes Problem um es unter gegebenen Bedingungen (verfuegbares Team, erforderliche Integrationen etc) einfacher handhaben zu koennen. Wenn du ein "Hallo Welt!" als verteilte Loesung super-skalierbar auf Azure installierst, dann befriedigt das ev. deinen Spieltrieb aber sicher nicht die Boerse deines Kunden.
Wenn du SOLID Prinzipien auf einen Anfaenger, der gerade seine ersten Programmierschritte macht (wie es offenbar Hannes' Zielgruppe ist) wirfst, dann wird der verstaendlicherweise hochgradig verwirrt sein.

Alles in allem wuerde ich mir wuenschen, dass Entwickler, insbesondere solche, die andere Entwickler schulen, Dinge differenzierter betrachten und und informierter vermitteln

Hannes Preishuber
24.07.2012 08:41:27 #

@Erich Inhaltlich trifft, das ziemlich gut. ( bei ein paar Punkten sehe ich das mein Punkt nicht gut genug rüberkam , zb ist klar das CCD nichts mit .NET zu tun hat.)
Natürlich sind Schulungsteilnehmer keine Profis, die seit 10 Jahren OOP machen. Du hast absolut richtig erkannt im Sinne eines besseren Ergebnisse, das abholen sinnvoller ist als verurteilen. Das Abholen muss auch in kleinen Schritten erfolgen. Was Ralf Westphal mit seinem Grade Konzept initiert hat, funktioniert in der Praxis erwiesener weise wenig. Und wir haben Ihn vom ersten Tag dabei unterstützt.

Dariusz
25.07.2012 10:50:39 #

Hannes,

wenn wir uns das nächste mal treffen gebe ich Dir ein Bier aus (falls Du Bier trinkst).