Du willst Debattieren - ok
"Verstand geht immer vor Technik" ist eine extrem unscharfe Aussage.
ist es nicht. Es ist eine extrem weitgefasste Aussage (bewusst) was die Bedeutung des Wortes Technik (Semeaphorus - was heißt das wörtlich übersetzt?) betrifft. In meinen Augen bezieht 'Technik' nicht nur Hard- und Software, sondern eben auch Arbeitstechniken und Prozesse ein. Egal um welche Technik es sich handelt: Eine Technik, der sich der Verstand unterordnen muss hat meiner Meinung nach auf dieser Welt nichts verloren.
Die komplexe Frage ist nicht das Tool, sondern vielmehr die Frage, wie man das Tool in seine Arbeitsweise integriert (da gibt es sehr viele Möglichkeitenj, eine Lernkurve und unterschiedliche Meinungen zwischen Team-Beteiligten).
Das ist nicht meine Frage. Meine Frage ist: Ist es effektiv (lang oder kurzfristig) das Tool X oder die Arbeitstechnik Y in meine tägliche Arbeit zu integrieren? Dabei ist mir meine 'Lernkurve' ziemlich egal - weil das Lernen an sich nicht mein Ziel ist (jedenfalls nicht in meinem Job). Ausdrücklich weise ich darauf hin, dass bei so einer Effektivitätsprüfung (ich unterscheide bewusst zwischen Effizienz und Effektivität) ein Tool eine Arbeitstechnik, ein Paradigma etc. jederzeit durchfallen kann und darf. So sehe ich zum Beispiel in meinem derzeitigen Betätigungsfeld (immer noch Notes-Entwicklung) überhaupt keinen Anlass mich mit Unit-Tests auseinanderzusetzen. Nicht mal privat - da ich nicht mal wissen kann, ob diese noch aktuell sind, wenn ich mal was anderes mache.
Das Gleiche gilt auch für z.B. UML, dass als OO-Tool kaum in meine tägliche Notes-Arbeit passt (ja ich weiß, dass sich Notes OO schimpft - ich glaube nur nicht wirklich daran...vielleicht in Teilen und Ansätzen).
Wenn man da immer sagt "Das sind nur Tools. Verstand geht vor Technik" etc. dann befindet man sich in genau dem inkonkreten Raum, wo man jede Hoffnung auf Fortschritt im Grunde aufgegeben hat, bzw. die Notwendigkeit für seine Projekte nicht sieht (oder hat). Mein Verstand braucht z.B. dringend Arbeitsmethoden, um effizient zu sein.
Ich habe keineswegs die Hoffnung auf Fortschritt aufgegeben - nur bin ich eben der Meinung, dass nicht alles was neu ist auch besser sein muss.
Mein Verstand soll lieber auch nicht effizient laufen - sondern möglichst effektiv...da schadet mancher Ballast und Overhead dann doch.
Netzübergreifende Anwendungen gab es schon vor Java. Z.B. Lotus Notes. Java ist gegenüber C++ eine sehr große Vereinfachung. Man kann mit Java nichts programmieren, was man nicht ähnlich auch mit C++ oder SmallTalk hätte machen können.
Es ist richtig, dass es netzübergreifende Anwendungen schon lange gibt - spätestens seit Unix. Es ist aber auch richtig, dass diese bis zum Internet Boom in den 90ern so gut wie keine kommerzielle oder allgemeine Verbreitung hatten, also eher die Ausnahme von der Regel waren, die da stand-alone Computing oder Zugriff auf Zentralrechner/lokales Netzwerk hieß.
Ein Massenbedarf an Internetapplikationen ist also erst durch die Verbreitung des Inter/Intranets entstanden.
Davon abgesehen kann man netzwerkübergreifende Software auch in Assembler oder Nullen und Einsen schreiben - es macht die Sache nur unnötig kompliziert.
Da ich z.Z. gerade wieder mal ein C++ Buch lese kann ich nachvollziehen, warum Java sich gegen dieses Monster aus Inkonsistenz so schnell in vielen Bereichen durchsetzen konnte. Das Bessere ist der Feind des Guten - somit hat Java für diesen Bereich eben im Moment die Vorherrschaft errungen - und mit was?
Mit Recht!
Noch was zu den alten Netzwerkübergreifenden Programmen, wie z.B. Notes. Dies waren durch die Bank weg Lösungen mit proprietären Protokollen. Netzwerkentwicklung im eigentlichen Sinn hat da nur die Firma Lotus betrieben - die Anwendungsentwickler haben sich unter Notes doch bis heute noch so gut wie nie um die Netzanbindung von Notes-Apps kümmern müssen.
Also ganz ehrlich: Ich habe gar nichts gegen Arbeitstechniken. Diese helfen vor allem bei der Kommunikation ganz gewaltig.
Ich entwickle gerade Notes-Software für ein Java Projekt (deren Doku System etc.) und bekomme daher dann doch einiges mit.
Ganz ehrlich bin ich erst mal davon begeistert, wie systematisch die vorgehen (auch wenn das wirklich sehr langweilig ist
). Da werden dann Use-Cases geschrieben, die in Test-Cases münden, zeitgleich mit der Entwicklung werden die JavaDocs und Unit Tests erstellt.
Über allem wurde dann das Paradigma 'SCRUM' gezogen und mit Tools wie QA-Run und eben Notes noch die letzten Ecken gepolstert.
Das finde ich schon hochprofessionell und gut. Das ganze hat nur einen Haken: Auch wenn die Entwicklung so vermutlich (ist ja noch nicht fertig) viel skalierbarer ist, am Ende gar billiger, ist sie vermutlich noch was anderes: Kleinen und mittelgroßen Unternehmen unverkäuflich.
Und mit noch einer anderen Sache habe ich ein Problem: Da arbeiten zur Zeit etwa 40 Leute an dem Projekt - und so richtig den Gesamtüberblick hat wohl niemand. Zwar alles Spezialisten auf ihren Gebieten - aber keine Universalisten - weil das aufgrund der Masse an Wissen wohl auch gar nicht geht. Genau an dieser Stelle aber wird mir Technik suspekt, wenn sie nämlich von Menschen nicht mehr verstanden werden kann. Ist meiner Meinung nach auch ein großes Risiko.
