Sonstiges > Offtopic

Anfänger in Foren

<< < (13/15) > >>

Marinero Atlántico:

--- Zitat von: Gandhi am 01.08.04 - 18:42:58 ---
Zu den ganzen Tools: Auch hier favorisiere ich meinen Verstand als wichtigstes Tool. Zwar helfen (je nach Tätigkeit) die diversen neuen Paradigmen der Softwareentwicklung beid der QS aber dennoch sind diese nur sinnvoll, wenn sie mit Maß und Verstand angewendet werden - und keinesfalls streng nach Dogma.
Was mich an der ganzen Tool Debatte aber sehr stört ist, dass da jedes Quartal eine neue Sau durchs Dorf getrieben wird.

Ich hätte da abschließend folgenden Vorschlag:
Verstand geht immer vor Technik.

--- Ende Zitat ---

"Verstand geht immer vor Technik" ist eine extrem unscharfe Aussage.

Oft geht es ja gar nicht um Tools sondern um Arbeitsweisen.
Bsp: Viele Leute haben in den letzten Jahren Test-First Programming, Unit-Testing verbunden mit JUnit in ihre Arbeitspraxis integriert. Das geht ja weiter als das Tool JUnit, weil es z.B. für .NET einen clone gibt. Das Thema ist auch nicht das Tool selbst, sondern das wie des Einsatzes.
Häufige automatisierte builds mit einer auf ANT oder was auch immer aufbauenden Umgebung ist auch so ein Punkt.
UML-Diagramme zur Planung/Dokumentation von OO-Projekten.
CVS ist wieder etwas.

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).

Da wird auch nicht jede Woche eine neue Sau durchs Dorf getrieben. Das sind vielmehr Ideen zur Arbeitsmethodik, die debatiert, übertrieben, kritisiert, etc. werden. Dort bilden sich dann unterschiedliche Meinungen heraus. Es gibt aber eine starke Tendenz hin zum Konsens.

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.
Die Meinung, dass wären alles little-consulting-bla-bla-to-sell-stuff teile ich nicht.
Im Grunde ist z.B. Test-First Programming nicht neu, sondern wurde angeblich stark auf IBM-Großrechnern anfang der 80er Jahre angewendet. In VB/Lotus Notes war es aber - glaub ich - unbekannt.

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. Die Idee einer Virtual Maschine, die einen plattformunabhängigen Zwischencode in OS-spezifischen Bytecode umwandelt stammt aus den 60ern.  

Gruß Axel

Gandhi:
Du willst Debattieren - ok 8)

--- Zitat ---"Verstand geht immer vor Technik" ist eine extrem unscharfe Aussage.

--- Ende Zitat ---
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.


--- Zitat ---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).

--- Ende Zitat ---
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).


--- Zitat ---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.

--- Ende Zitat ---
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.



--- Zitat ---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.
--- Ende Zitat ---
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.

Semeaphoros:
Technik: Geht auf das griechische Word "techne" zurück, heisst die Kunst, und genau wie das deutsche Kunst ist techne von "können" abgeleitet.  Techne ist sowohl die Kunst, das Können (Wissen, KnowHow und was immer) des Handwerkers wie des Bildhauers/Künstlers (in unserem Sinn). Das Adjektiv "technikos", wovon Technik direkt abgeleitet werden kann, bezeichnet alles, was irgendwie das Können betrifft, und dies sowohl im künstelerischen wie auch im handwerklich-technischen Bereich, und wenn heutige Massstäbe schon damals Gültigkeit gehabt hätten, beinhaltet das auch das "Können", KnowHow im wissenschaftlichen Bereich.

Marinero Atlántico:

--- Zitat von: Gandhi am 02.08.04 - 10:55:49 ---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.

--- Ende Zitat ---
Kommt natürlich auf die Größe und Komplexität des Projekts an. Wir haben Projekt-Teams von 1 bis 5 Leuten. Zählt man die Leute auf kundenseite hinzu, sind es mehr.
Selbst bei 3 Leuten braucht man klare Arbeitsprozesse. Natürlich nicht so ausdifferenziert wie bei 40 Leuten, aber immerhin.

Gruß Axel

Gandhi:
Gut zu wissen, dass es geht. Aber so, wie Du hier im Forum auftrittst - damit meine ich das (durchaus nicht negativ gemeinte) Herumjonglieren mit Akronymen und Fachterminologie - würde ich mich als Kunde, der ja als Nichtexperte anzunehmen ist (sonst würde er ja niemanden mit so was beauftragen) doch sehr erschrecken/verängstigen/verunsichern. Das mal nur nebenbei gesagt.

Zurück zum außergebietlichen Thema:
Was bei dieser Diskussion um die effizienteste Arbeitsweise oft vergessen wird (ist mein Eindruck) ist, worum es hier im Ansatz eigentlich ging:
Viele dieser Techniken wollen das Problem lösen, dass innerhalb der Projekte oft zu wenig gesprochen wird, bzw. sich nicht verstanden wird oder nicht darüber geredet wird, was eigentlich getan wird (z.B. SCRUM, UML, ...). In der Praxis fürht das meinem Empfinden nach aber dazu, dass man sich dieses Themas durch die Technik entledigen will. Das heißt, man redet nicht mehr, weil man ja UML/Use-Cases einsetzt.

Ähnliches ist immer auch bei anderen Bereichen zu befürchten. Beispiel: QS: Wenn ich Test-Tools (zb. JUnit, QARun, ...) einsetze kann dies zu einer Art Betriebsblindheit aufgrund falscher Sicherheit, die einem so eine Technik vermittelt führen.

Aus genau diesem Grund bin ich der Meinung, dass der Verstand immer vor der Technik gehen muss - im Zweifelsfall schon um diese selbst nichtperfekten Konstrukte zu überwachen.

Auch kann es ganz schnell dazu führen, dass Dinge benutzt werden, die gar nicht gerechtfertigt sind. Mit Kanonen auf Spatzen schießen. Und so behaupte ich eben, dass es nicht in allen Projekten angebracht ist, mit der Kanone der allumfassenden Technologiekeule um sich zu schießen. Auch hier bedarf es des korrigierenden, wachen und emanzipierten Verstands

Hört sich banaler an, als es ist...

Es gab mal eine Statistik zu gescheiterten Projekten. Da hieß es, dass >80% der Projekte nicht aufgrund technischer, sondern aufgrund kommunikativer Probleme scheitern.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete