Mich würden mal eure Meinungen zu dem Thema interessieren.
:
Gesperrt durch User
Laut Wikipedia eine der Methoden, die uns derzeit die unsäglich unbrauchbare Software beschert, die uns so umgibt. Aufgabe zu schwer? Kein Problem, programmier was anderes als der Kunde will und laber ihm die Taschen voll. Jeden Tag ein neues Ziel, klar, wenn der Weg das Ziel ist, weil man nach Arbeitsstunden und nicht Ergebnis bezahlt wird. 3 teamunfähige Mitarbeiter? Kein Problem, wir haben für jeden eine Aufgabe, die zwar keine einzige Codezeile produziert, dafür aber um so mehr heisse Luft. Und jemand verdient am "zertifizieren", geile Geschäftsidee, solche Torfnasen auch noch abzuziehen.
[ ] Du hast verstanden, was SCRUM-Entwicklung ist
Ich finde die Idee die hinter Scrum steht interessant. Ich kann mir auch gut vorstellen das man mit SCRUM die Entwicklung beschleunigen kann, da den Entwicklern erheblich mehr Entscheidungskompetenz zugebilligt wird. Habe allerdings selbst noch keine Möglichkeit gehabt, SCRUM auszuprobieren.
Unsere Software-Entwickler-Truppe mit 6 Leuten hier macht das nach Scrum. Und seit die so organisiert arbeiten, klappt das sehr gut und vor allem schnell. Bei uns in F&E ändern sich ständig die Anforderungen, da passt Scrum sehr gut.
Scrum ist sicherlich die kompromissloseste Version des Agile Programmings. Mir geht es etwas zu weit. Ich würde Firmen die nach einem neuen Vorgehensmodell suchen am ehesten eXtreme Programming empfehlen. Ist änhlich flexibel, aber definiert auch einige notwendige Prozesse. @MAWIN: Sorry, Du hast überhaupt nichts verstanden und anscheinend noch nie an einem größreren Softwareprojekt gearbeitet, das nach Kundenspezifiktationen entwickelt werden musste. Sich ändernde Anforderungen sin heutzutage die Regel, da ist Agile Programming die einzige Antwort darauf Gruß Tom
> @MAWIN: Sorry, Du hast überhaupt nichts verstanden
Wahrscheinlich nicht.
Wir haben wenigstens noch funktionierende Software geschrieben, und das
im Gegensatz zu unseren Mitbewerbern termingerecht und kostengünstig.
Mit mehr Dampfplauderern wir dir hätten wir mehr verdient und wären
immer noch nicht fertig.
@MaWin: Ach wirklich! Dann seit Ihr die große Ausnahme in der Softwarebranche der letzten Jahrzente. Ok, kommt natürlich auch darauf an, wie komplex eure systeme waren und wie sehr eure software mit Userinteraktionen zu tun hatten und wie bereitwillig sich die Nutzer der Software untergeordnet haben. (Im Übrigen habe ich 20 Jahre Softwareentwicklung & Beratung zu, Thema Entwicklungsprozesse hinter mir) also halte Dich mal mit Beleidigungen ala Dampfplauderer zurück, vor allem da Du Dich über Wikipädia hinaus wohl nicht dmait beschäftigt hast. Tom
Ach ja, wenn Du der Meinung bist, dass diese Herren hier: http://agilemanifesto.org/ alle keine Ahnung haen, dann weiß ich auch nicht mehr weiter :-( Tom P.S.: Und sag mir jetzt bloß nicht, die Namen sagen Dir nichts
> wie komplex eure systeme waren
Ein schönes Beispiel, weil etwas praktisch identisches nun 15 Jahre
später von 10 Jahre Jüngeren gerade nachprogrammiert wird:
Es war 1/10 so komplex, bestand aus 1/1000 so viele Bytes, war 1/100 so
arbeitskostenäufwändig, hat aber das 3-fache (schön wäre jetzt 10-fache
zu sagen, stimmt aber nicht) an Funktionalität gehabt (weil die Herren
2/3 einfach weglassen), braucht 1/100 so viel Speicher und läuft 10 mal
schneller.
Wir sind oder waren nicht mehr Ausnahme, als heute, denn auch heute
werden 90% der IT-Projekte nicht rechtzeitig fertig und liefern zum
Schluss nur eine Bruchteil des gewünschten Effekts zum mehrfachen Preis.
Das war früher so, und ist auch heute so, unabhängig von der
Entwicklungsmethode die sich nämlich meist nur in den verwendeten
Abkürzungen unterscheiden. Nur hat man inzwischen das Scheitern zum
Normalfall erklärt. Bugs werden nicht mehr behoben, sondern zum Feature
erklärt.
Zwar gibt es heute einige Programme, die überzeugen können (meist ältere
die schone eine vieljährige Geschichte haben), aber der weitaus grösste
Teil ist eine Beleidigung für jeden, der programmieren kann.
Insbesondere im Mitmach-Web (Wiki, Foren) fühlt man sich 40 Jahre
zurückversetzt, wenn Eingabefelder Steuerzeichen wie zu
Wordstar's-Zeiten erfordern statt WYSIWYG, wenn Flash-Spiele an die
Steinzeit der Atarispielstationen erinnern, oder Contentsoftware von
WebShops oder Zeitschriften offensichtlich einen Pflegeaufwand
erfordern, der sogar über handschriftlich erstellte Kataloge hinausgeht.
Schliess für dich eine Versicherung ab, und beurteile die
Tarifberechnungssoftware, die meist winzige Dialoge ohne Unterstützung
des "Zurück" Buttons mit sinnlosen Eingabeldern enthält, also alles
andere als kundenorientiert ist sondern schwer an BASIC-Taschenrechner
von 1980 erinnert (nur wurde damals das Tarifrechnungsprogram mit 1/100
des Aufwands erstellt).
Sorry, aber der Softwarebranche geht es verdammt schlecht, zwar sind
viele Leute damit beschäftigt, möglichst wenig zu produzieren, aber was
die Dampfplauderer produzieren können, sind 3-buchstabige Abkürzungen in
Massen, damit man jeden Tag eine Sau durch's Dorf treiben kann, auch
wenn es immer dieselbe Sau ist. Wirklich kluge Softwareentwickler gibt
es heute vermutlich genau so viele wie vor 10, 20, 30 Jahren, aber es
gibt heute tausende mehr Dampfplauderer (Seiteneinsteiger) die sich für
klug halten.
MaWin: Sicherlich wird heute noch genauso viel schlechte Software oder Software schlecht entwickelt. Das liegt aber kaum daran, dass die heute alle SCRUM oder ähnliches verwenden, sondern gerade weil sie es noch nicht tun! Ich weiß nicht was für eih Vorgehensmodell Ihr immer verwendet habt, hört sich aber stark nach Wasserfall an. Daher bitte schau Dir Agile erst mal genauer an, bevor Du hier Ansichten vertrittst, die schlichtweg unfundiert sind! Das es gerade im Web jede Menge grausame Software gibt, völlig klar. Aber gerade bei der von Dir gescholtenen Mitmachsoftware gibt es ja wohl genug super beispiele (ich sag nur mal Linux, aber auch viele andere) Gerade durch die heute überall verfügbare Onlineverbindungen ist ein "Täglicher" Rollout erst möglich geworden und ermöglicht schnelle Korrekturen und Verbesserungen, ein Kernthema in Agile. Die Versprechen die Agile Teams machen, sind zumindest zuverlässig, auch wenn es nur in kleinen Schrittchen geht, aber dafür verpsricht man dem Kunden nicht das blaue vom Himmel und verlangt am Ende das doppelte und ist immer noch nicht fertig. Wer sich für eXtreme Programming interessiert, dam kann ich nur dieses Buch empfehlen: http://www.amazon.de/Planning-Extreme-Programming-Kent-Beck/dp/0201710919/ref=sr_1_3?ie=UTF8&s=books-intl-de&qid=1260802212&sr=1-3 Ach noch was: Wenn sämliche Anforderungen für die nächsten 5 Jahre festgezogen sind und sich sowieso nicht ändern werden und gesetzliche umfachreiche Dokumentation pflicht ist, dann macht Agile natürlich wenig Sinn (Militär, Medizintechnik und ähnliches) In allen anderen Fällen dürften sowohl Kunden als auch Entwickler davon profitieren. Gruß Tom
Thomas Burkhart schrieb: > In allen anderen Fällen dürften sowohl Kunden als auch Entwickler davon > profitieren. Wie bei allen Religionen duerften Diskussionen wohl herzlich sinnlos sein... aber sei's drum. Zuersteinmal: Nur, weil da ein paar Herren eine Webseite mit ihrer Theorie vollgemalt und am Besten noch ein paar Buecher dazu produziert haben, gibt das ihren Aussagen noch kein Fundament. Das sieht man leider in vielen fundamentalistischen Debatten heute: Veroeffentlichung wird als voellig ausreichende Legitimierung angesehen. "Agile" oder "eXtreme" habe ich schon entwickelt, da gab es diese Begriffe noch gar nicht. Das war fuer mich eine ganz normale Art zu entwickeln, wenn das Umfeld gepasst hat. Heute wollen mich Leute zu diesen Methodiken bekehren, die letztes Jahr noch einer anderen Sau hinterher gerannt sind. Und naechstes Jahr gibt es dann die naechste Sau. Dann entwickle ich immer noch auf eine Art, die ich einfach dynamisch, flexibel und vorrausschauend nenne. Die Kollegen haben dann wahrscheinlich die naechste Projektkatastrophe hinter sich und probieren die naechste Methodik aus, anstatt den Fehler mal bei sich zu suchen. Was leider bei all diesen Methoden uebersehen wird: Sie machen aus schlechten Entwicklern keine guten Entwickler. Und gute Entwickler brauchen keinen hohen Glauben, dem sie nachlaufen, um gut zu entwickeln. Nur leider sind die meisten Entwickler nicht gut und noch viel schlimmer: sie merken es nicht. Sie merken oft auch nicht, dass sie die Letzten sind, bei denen diese dynamischen Methoden funktionieren und die so arbeiten koennen. Das Ganze erinnert mich irgendwie an die antiauthoritaere Erziehung. Fuer eine Minderheit eine grossartige Chance, sich zu entfalten - fuer den Rest Chaos. Speziell zu Agile Development und Verwandten ist leider festzustellen, dass diese von sehr vielen Leuten lediglich als Ausrede fuer Schlamperei genutzt wird. Keine Dokumentation -> Agile. Haelfte der Features fehlt -> Agile. Keiner Zustaendig -> Agile. Die gleichen Geschichten laufen auch bei den richtigen Tools, den richtigen Sprachen, etc, pp. Am Ende sind das alles nur tragische Versuche, den Mangel zu verwalten - den Mangel an guten Entwicklern. P.S: Vorwuerfe wie (frei) "ihr benutzt ja bestimmt noch die Wasserfall-Methode..." sind der Brueller :-)
Hallo Peter, unabhängig davon, dass die genannten Herren auch Bücher zu dem Thema verkaufen sind es Leute die Jahrzente Erfahrung in großen Projekten gemacht haben. Ich stimme Dir 100% zu, dass man ohne gute Entwickler keine gute Software schreiben kann, egal was für ein Vorgehensmodell verwendet wird. Aber: Ich schreibe hier weit von einer Glaubensdiskussion entfernt, sondern einfach aufgrund meienr Erfahrung in Projekten. Gerade eXtreme Programming ist ja gar nicht so Antiautoritär wie Du sagst, da gibt es ja einige sehr klare Regeln. Agile als Entschuldigung ist natürlich Mist, wobei Agile als Ausrede von fehlenden Features wohl kaum ziehen dürfte, da Agile ja auf enge Rückkopplung zum Kunden ziehlt. Wie soll da auf einmal überrascht festgestellt werden, dass was fehlt. Dass sollte allen die ganze Zeit klar gewesen sein und auch so vereinbart gewesen sein, sonst wurde hier nich nach XP gearbeitet. Agile Projekte sind auch dann zum scheitern verurteilt wenn eine Organisation und das dazugehörige Management nicht dahinter stehen. Wenn es richtig gemacht wird, sollte man keine unangenehmen Überraschungen erleben dürfen. Das der Wasserfall für Projekte mit einer Laufzeit >1/2 die falsche Wahl ist, dazu stehe ich, auch wenn Du das lustig finden magst. Ich habe den ganzen Ideologischen Kram hinter mir, so dass ich keinen Glaubenskrieg hier führe. Fakt ist, dass Benutzer/Kunden heute davon ausgehen, dass sich Software jederzeit ändern läßt, daher braucht man auch ein flexibles Arbeitsmodell. Kuckt euch doch mal an in welch kurzen Zyklen Ihr updates für Firefox, iTunes, Skype und was sonst noch alles bekommt, dass enspricht einem Agilen vorgehen und nicht einer Jahresmäßigen Releaseplanung. Aber wie Du schon sagtest es kommt auf gute Entwickler an, das ist das A&O. Gruß Tom
> Wasserfall für Projekte mit einer Laufzeit >1/2 die falsche Wahl > ist, dazu stehe ich, auch wenn Du das lustig finden magst. Lustig? Eher traurig. Wasserfall sagt, dass man ein Projekt in mehrere Teilprojekte aufteilen kann, die man nacheinander macht, wobei man ein fertiges Teilprojekt nicht mehr anfassen muss, weil es richtig und ausreichend ist. Damit hat man in der Summe am wenigsten Arbeit gemacht, und auch wenig überflüssigen, also hinterher nicht mehr verwendetes produziert. Im Interesse der Kunden und deren Budget also das Beste was möglich ist. Daß du das so nicht siehst, zeigt deine mangelnde Kenntnis der wahren Welt. Jeder Produktionsprozess, bei dem man aus Erfahrung weiss wie er geht, wird so gemacht, bei Haus baut man erst das Fundament, dann die Mauern, dann stellt man die Badewanne rein, und man muss nicht das Fundament ändern weil die Badewanne hinterher doch grösser ist als gedacht. Auch beim Auto fängt man nicht hinterher an, die Motorhaube auszubeulen, weil der Motor nicht reinpasst, das ist einfach kluge Arbeit. Ein Hausbesitzer, dem du mit agiler Bauweise kommst, wird dich zu Recht zu Tode prügeln, eine Autofabrik, der du agile Autoproduktion vorschlägst, an die Wand nageln. Leider sind wir bei Softwareentwicklung noch nicht soweit, daß alles auf den ersten Ansatz hin klappt, auch wir müssen hin und wieder mal bereits erstellte Teilmodule nachbessern, aber das ist stets ein Fehler gewesen, der in der Summe mehr Arbeit produziert, und damit dem Kunden mehr Kosten. SCRUM ist nichts weiter, als die geglaubte Legalisierung zu dummer Programmierer und vor allem zu dummer Projektmanager. Dabei muss man in einem Team ganz anders rangehen, damit auch mit dummen Programmieren was Gutes bei rauskommen kann.
Sorry, aber Deine Metaphern stimmen eben gerade be Software nicht! Die Hausbau Metapher wurde oft bemüht, vermittelt aber eben genau den Eindruck, dass Software so statisch sei, dass nach der Grundsteinlegung nichts mehr gemacht werden darf. Kunden von heute sind sich aber bewußt, dass es um Software zu ändern eben nicht einer neuen Gußform bedarf oder dass dafür erst noch mal ne neue Platine produziert werden muss, daher erwarten Sie, dass auch kurz gegen ende noch ein zweites Badezimmer im Dachboden möglich ist. Wer hier auf Wasserfall setzt kann jetzt prima gegenüber dem Kunden den Vertrag nebst Pflichtenheft und seinen Anwalt rausholen und vielleicht auch sein geld bekommen, ob er den nächsten Auftrag bekommt ist fraglich. Im übrigens ist Wasserfall nicht das was Du beschreibst, dass man teilprojekt um Teilprojekt nacheinander macht. Wasserfall bedeutet, dass: 1. Alle Anforderungen gesammelt und festgehalten werden 2. Ein gesamtes Systemdesign gemacht wird 3. Implementiert wird 4. getested Dabei sind keine abweichungen durch sich änderende Anforderungen vorgesehen. MaWin: So wie Du schreibst hast Du dich bisher noch nicht einmal ernsthaft informiert, was Agile programming eigentlich ist, daher denke ich bringt eine Diskussion auf dem Niveau ala >SCRUM ist nichts weiter, als die geglaubte Legalisierung zu dummer >Programmierer und vor allem zu dummer Projektmanager. Dabei muss man in >einem Team ganz anders rangehen, damit auch mit dummen Programmieren was >Gutes bei rauskommen kann. nicht besonders viel. (Mit Dummen programmierern bekommt man eh nichts vernünftiges hin) Gruß Tom
MaWin schrieb: >> Wasserfall für Projekte mit einer Laufzeit >1/2 die falsche Wahl >> ist, dazu stehe ich, auch wenn Du das lustig finden magst. > Lustig? Eher traurig. Traurig ist, dass ich eigentlich was ganz Anderes geschrieben hatte... > Wasserfall sagt, dass man ein Projekt in mehrere Teilprojekte aufteilen > kann, die man nacheinander macht, > wobei man ein fertiges Teilprojekt nicht mehr anfassen muss, weil es > richtig und ausreichend ist. Was idealisiert und unrealistisch ist. Das Wasserfallmodell funktioniert erst, wenn das Wasser wieder rauffliessen kann :-) > Auch beim Auto fängt man nicht hinterher an, die Motorhaube auszubeulen, > weil der Motor nicht reinpasst, das ist einfach kluge Arbeit. Oh, der schoene Analogienspass. Nur ignorierst auch du hier, dass Softwareentwicklung kein "einfacher" Fertigungsprozess ist. Zumindest nicht einfach der Teil, der ab dem fertigen Plan, der durch Prototypen und Vorserien bestaetigt ist. Wenn schon so ein Vergleich, dann fang auch bei der Entwicklung an.
Peter Stegemann schrieb: > MaWin schrieb: >>> Wasserfall für Projekte mit einer Laufzeit >1/2 die falsche Wahl >>> ist, dazu stehe ich, auch wenn Du das lustig finden magst. >> Lustig? Eher traurig. > > Traurig ist, dass ich eigentlich was ganz Anderes geschrieben hatte... Dann hab ich da Dich da wohl falsch verstanden. Tom
> Mit Dummen programmierern bekommt man eh nichts vernünftiges hin Du nicht. Haeuser baut man aber auch nicht mit einer Horde Bauings. Die Softwarebranche hat noch viel zu lernen. Aber so lange sie lieber Bullshit-Bingo spielt... > hast Du dich bisher noch nicht einmal ernsthaft informiert, was Agile programming eigentlich ist Glaubst du. Immerhin habe ich erkannt, daß bereits die grundlegenden Richtlinien Bullshit sind. Du wirst noch viel lesen, und es immer noch nicht merken.
MaWin schrieb: >> Mit Dummen programmierern bekommt man eh nichts vernünftiges hin > > Du nicht. > > Haeuser baut man aber auch nicht mit einer Horde Bauings. > > Die Softwarebranche hat noch viel zu lernen. > Wow, MaWin hat den Stein der Weißen, den wir andere seit 20 jahren suchen ;-) Genau, wir brauchen zukünftig nur noch einen Guten Softwarearchitekten und dann ganz viele dumme programmiersklaven. LOL Genau diese Versprechen konnte noch nirgends in umgesetzt werden. Programmieren heißt entwickeln und da wird genauso gepröbelt wie bei anderen Ingeneuren auch. Das die Leute Produktion/Häuser bauen immer mit Entwicklung verwechseln müssen. Zum Produzieren von Software (brennen der CDs brauche ich nur nen praktikanten), aber zum Rest dann halt doch besser Ingeneure/Gute Programmierer. > Aber so lange sie lieber Bullshit-Bingo spielt... > >> hast Du dich bisher noch nicht einmal ernsthaft informiert, was Agile > programming eigentlich ist > > Glaubst du. > Immerhin habe ich erkannt, daß bereits die grundlegenden Richtlinien > Bullshit sind. > Du wirst noch viel lesen, und es immer noch nicht merken. Komm mal von Deinem hohen Ross runter, informier Dich gefälligst und probiers auch mal aus, bevor Du hier solchen Stuss von Dir gibts. Alles was Du bisher zu bieten hattest waren Vorurteile und halbwissen. Tom
Genau, wir brauchen zukünftig nur noch die freie Anarchie bei der Softwareentwicklung und plötzlich kommen ganz tolle Programme bei raus. LOL Genau diese Versprechen konnte noch nirgends in umgesetzt werden. Hínt: SCRUM fördert nicht so Erfahrene nicht.
> Genau, wir brauchen zukünftig nur noch einen Guten > Softwarearchitekten und dann ganz viele dumme programmiersklaven. Thomas, das ist genau das, was gefordert ist. In vielen Firmen herrscht Mangelverwaltung und wie gesagt, besteht der Mangel in guten Leuten. Es ist daher einfacher, EINEN Kopf und VIELE Hände zu nehmen, statt WENIGE gute Köpfe. Es sind die Randbedingungen der Wirtschaftler, die das vorgeben. Und ich stimme darin überein, daß - egal, wie die Methode heissen mag - es immer darum geht, eine Horde zu verwalten. Echte Köpfe organisieren sich im Team und entwickeln adaptiv, also an der Situation entlang. Methoden sind nur da, um Grobvorgaben für die Schwachmaten zu erschaffen.
Wir entwickeln hier auch nach SCRUM. Also offiziell. Real machen wir es so, wie schon immer.
MaWin schrieb: > Genau, wir brauchen zukünftig nur noch die freie Anarchie bei der > Softwareentwicklung und plötzlich kommen ganz tolle Programme bei raus. > LOL > Genau diese Versprechen konnte noch nirgends in umgesetzt werden. > > Hínt: SCRUM fördert nicht so Erfahrene nicht. Du hat es immer noc nicht verstanden. Ich spreche hier von einem vernünftigen Agilen Prozess wie XP (SCRUM ist mir selbst auch zu locker), das hat mit Anarchie nichts zu tun. Mach Dich bitte erst mal kundig statt hier nur inkometent und polemisch daherzuschreiben. Tom
Alf schrieb: >> Genau, wir brauchen zukünftig nur noch einen Guten >> Softwarearchitekten und dann ganz viele dumme programmiersklaven. > > Thomas, das ist genau das, was gefordert ist. In vielen Firmen herrscht > Mangelverwaltung und wie gesagt, besteht der Mangel in guten Leuten. Es > ist daher einfacher, EINEN Kopf und VIELE Hände zu nehmen, statt WENIGE > gute Köpfe. > > Es sind die Randbedingungen der Wirtschaftler, die das vorgeben. > Viele Unternehmen sollten mal den Klassiker "The mythical man month" lesen. Darin wird statistisch sehr schön dargelegt wie die Produktivität von Softwareteams mit der Größe sinkt. Eine kleinere Gruppe guter Köpfe die sich nicht mit der Organisation vieler Hände sondern mit Coden beschäftigen können wären oft viel produktiver. Wenn eine Firma von einem Kopf verlangt viele Hände zu koordinieren, dann ist Agile wahrscheinlich nciht so ideal. Wenn es mindestens halb so viele gute Köpfe gibt, dann sollte man mal Pairprogramming ala XP versuchen, bildet die Hände schnell weiter. > Und ich stimme darin überein, daß - egal, wie die Methode heissen mag - > es immer darum geht, eine Horde zu verwalten. Echte Köpfe organisieren > sich im Team und entwickeln adaptiv, also an der Situation entlang. > > Methoden sind nur da, um Grobvorgaben für die Schwachmaten zu > erschaffen. Ja, genau das war der Versuch bei allen stark formalen Prozessen ala RUP oder V-Modell. Wenn das der Grund für solche Prozesse ist, dass man angst hat, die Affen im Team verauen das Projekt, dann wurde der Sinn von Prozessen nicht verstanden. Schaut euch bitte erst mal an was z.B. eXtreme Programming zu bieten hat. Und selbst da saggt Kent Beck, man solle es nicht als Bibel verstehen sondern die Teile nutzen die einem helfen. Tom
Gerry E. schrieb:
> Habe ich da jetzt ISO 9000 rausgelesen?
Ja, das war die Vorstellung Ende der 90er, dass man Softwareentwicklung
genau so organisieren könne wie ein Produktionsunternehmen dabei
entstanden extrem Dokumentationslastige Entwicklungsprozesse. Die Teams
eher gelähmt als wirkliche Vorteile gebracht haben.
Software ist eben nicht Produktion sondern Entwicklung, da braucht es
mitdenkende Köpfe.
Tom
Thomas Burkhart schrieb: > Software ist eben nicht Produktion sondern Entwicklung, da braucht es > mitdenkende Köpfe. Ich würde sogar noch weitergehen und sagen: Software entwickeln hat mehr mit Erfindertum zu tun als mit klassischer Entwicklung. Ein Entwicklungsingenieur bei Mercedes hat vorher schon an x Autos mitgearbeitet und weiß im Prinzip worauf man beim Autobau achten muss. Ein Architekt hat schon x Häuser gebaut, ehe er das aktuelle in Angriff nimmt. Ein Brückenbauer baut die x-te Brücke. Aber egal wie neu das alles ist, das Ergebnis ist immer noch ein Auto, ein Haus, eine Brücke. Softwareleute haben das Problem, dass ihre Aufgabenstellung (im Idealfall) vorher noch nie jemand gemacht hat. Es existieren daher keine bis wenige Erfahrungswerte für die konkrete Aufgabenstellung. Oder wie ein ehemaliger Mitstreiter von mir zu sagen pflegte: "Erfindungen lassen sich nicht zeitlich vorhersagen"
Der Haken an Programmierern ist, dass jeder glaubt, ein ganz kreativer genialer Kopf zu sein. Das trifft auf ~ 1% zu, ~ 10% sing gut, der Rest sind grad mal so als Prorgrammierknechte zu gebrauchen, wenn man's schafft, die Kerle an die Vorgaben zu binden. Das funktioniert aber erst dann, wenn die Herren mitbekommen, dass sie Maurer am Bau sind, und keine Kunstschmiede.
> Softwareleute haben das Problem, dass ihre Aufgabenstellung > (im Idealfall) vorher noch nie jemand gemacht hat. Prust, an Überheblichkeit mangelt es dir nicht... Begegne damit keinem Architekten auf einer Party. Das letzte innovative Softwareprodukt ist sicher länger her, als das letzte innovative Bauwerk. Dafür wird gerade sicher an 1000 weiteren schlechten WebShopFrontends geschrieben.
MaWin schrieb:
> Begegne damit keinem Architekten auf einer Party.
Da hätte ich kein Problem mit. Hauptsache, ich begegne auf einer Party
nicht jemandem wie dir...
@khb: SW-Entwicklung ist nicht gleich SW-Entwicklung. Ich kenne eine Firma, die machen Werbekram. Also irgendwelche Websites mit Datenbankkram dahinter und nutzen alle Monster-Bibliotheken und Frameworks, die in der Java-Welt herumschwirren. Das ist eine ganz andere Entwicklung und besser planbar (wenn sie es denn machen würden) als im technischen Bereich, von dem du vrmtl. sprichst. Ich denke, nicht überall in der SW-Entwicklung sind die gleichen Ansätze sinnvoll. Insofern verstehe ich nicht ganz, wie man sich darüber aufregen kann, welcher Weg der bessere ist, ohne das Ziel zu kennen :-( (damit meine ich jetzt wieder eher weniger dich)
> Du hat es immer noc nicht verstanden. Ich befürchte, DU hast nicht verstanden... > Ich spreche hier von einem vernünftigen Agilen Prozess > wie XP (SCRUM ist mir selbst auch zu locker), ...daß es in diesem Thread um SCRUM geht. Schön, daß du der Julia jetzt sagst, daß du davon (auch) nichts hältst. Dann sind wir doch einer Meinung. Das hat jetzt aber lange gedauert, bis DAS nach deiner Anfangsbockigkeit rauskam. Und wie Peter schon schrieb: "agile" haben viele schon programmiert, da wusste die Welt noch nicht, wie man das schreibt. Denn so geradlinig sauber arbeitskräftesparend wie "waterfall" auch wäre, leider waren wir (und die Kunden) nicht so gut, es so sauber geradlinig durchziehen zu können. > Mach Dich bitte erst mal kundig ...geht ganz klar an deine Adresse. Du solltest schon wissen, in welchem Film du sitzt.
Der Fisch stinkt vom Kopf her. Solange man als Entwickler ungefähr 20 Stunden im Monat braucht, um seine Arbeitszeit zu verwalten, in vorgefertigte Stundensheets zu packen, und diesen bis zur Genehmigung nachzulaufen, solange die Projektleiter bis hin zum mittleren Management vor lauter Kontrollgeilheit ständig Labermeetings ansetzen, weil die in dem Management-Crashkurs so gelobt wurden, und solange aus Ohnmacht und Versagenspanik alle Kritik und Probleme überhört werden, und nur positive oder geschönte Meldungen in der Hierarchie nach oben weitergegeben werden, solange ist das Vorgehensmodell unser geringstes Problem. Die besten Projekte sind doch die, wo der Projektleiter das Entwicklungsteam vor den Strukturen der Firma schützt, und sie einfach ihre Arbeit machen läßt. Die beste Aussage von einem Projektleiter: "Wir haben agile Entwicklung vom Kollegen Müller einen Monat lang ausprobieren lassen, das ist nichts für uns". Oder die andere Projektleiterin, die plötzlich allen Anforderungen die Priorität "1" gegeben hat, damit alles schneller fertig wird. Wer das Entwicklungsteam vor solchen Entscheidern beschützt, der wird auch mit guter Software belohnt.
> Der Haken an Programmierern ist, dass jeder glaubt, > ein ganz kreativer genialer Kopf zu sein. Das Und der tatsächliche Haken ist, dass effektive Softwareentwicklung im Team nicht- aber auch garnichts mit der viel beschrienen Kreativität zum tun hat, sondern Disziplin und Ordung erfordert. Und, das Team muss eingespielt sein und darf nicht ständig mit neuen Verfahren überzogen werden. Ich mache mit meinem Team nun seit 15 Jahren große Projekte und wir haben so ziemlich alles überlebt, was von Dogmatikern in dieser Zeit aufgeworfen wurde: 1995 OOP: ALles muss nach OOP programmiert werden. OO ist gut. 1997 CSM: Das erweiterte Client-Server-Modell. Muss sein. Die Zukunft ist das ! 1999 UML! Alles, aber auch alles muss mit UML gemacht werden. UML ist gut! 2001 Extreme - Programming - seither sind wir extrem gut. 2003 SRUM! srum di dum di dum di dumm .. 2005 MISRA-C: Es gibt nirgendwo auf der Welt, was Besseres MISRA ist spitze. 2007 RSC: Restrukturierbarer Selbstorganisierter Code - ja is klar, Herr Schwan. 2009 ACC: Nie wieder darf etwas ohne automatic code generation gemacht werden Alles grosses Methodengequatsche von Leuten die erkannt haben, daß sie mit SW nicht klarkommen und lieber Doktrinen bewerben, vertreiben und an ihnen verdienen möchten. Letzten Monat habe ich für eine Prozessorsteuerplattform mit 3 Leuten aus dem Nichts eine lumpige Steuerung in C ohne jegliches Betriebsystem aus dem Boden gestampf. Wir haben 90% des Tages damit verbracht, uralten C zusammenzulinken. Am Ende war es in Windeseile fertig. Wir haben nach der Methode "schnell fertig werden" , "baue effektiv", "bring es zum laufen", "sieh zu, dass es fehlerfrei is", "möglichst wenig testaufwand" programmiert. Keine Ahnung, welche Methoden wir da im Detail genutzt haben - aber wir waren sehr agil, orientiert und extrem schnell fertig. Der Grund: Wir mussten es selber machen, weil es in ganz Europa keine Softwarefirma gab, die uns einen Termin von unter 6 Wochen genannt hat und einen Preis unter 75k. Gekostet hat uns die Geschichte hier 450 Mannstunden.
Korrektur: 435 Mannstunden - inklusive meiner dafür notwenigen Projekttätigkeit.
MaWin schrieb: >> Softwareleute haben das Problem, dass ihre Aufgabenstellung >> (im Idealfall) vorher noch nie jemand gemacht hat. > > Prust, an Überheblichkeit mangelt es dir nicht... Warum? Wenn mich jemand fragt, wie lange es dauert, bis er einen voll funktionsfähigen 3D-Editor kriegt, der nur mit Nurbs arbeitet und Solid-Modelling beherrscht, dann muss ich ihm sagen: Ich habe keine Ahnung. Ich bin jetzt seit 25 Jahren im CAD, aber ich weiß nicht wie lange ich dafür brauchen würde. Wenn es etwas bereits fertiges dafür gibt, dann unbedingt kaufen. Egal was es kostet, denn um den Preis kann ich ihm das mit Sicherheit nicht machen. Klar kommt es auch zu Doppelentwicklungen. Aber kein Kunde würde Geld in das nächste Spreadsheet-Programm investieren. > Das letzte innovative Softwareprodukt ist sicher länger her, > als das letzte innovative Bauwerk. Das glaube ich nicht. Aber dazu muss man auch über den Tellerrand der WebShopFrontends lugen. Gerade im technischen Bereich gibt es immer wieder neuartige Software-Ansätze.
> > > Softwareleute haben das Problem, dass ihre Aufgabenstellung > > > (im Idealfall) vorher noch nie jemand gemacht hat. > > > Prust, an Überheblichkeit mangelt es dir nicht... > Warum? Weil wir gerade neulich auf einer Party laut darüber nachgedacht haben, dass es in den letzten 10 Jahren eigentlich verdammt wenig bedeutende neue Software gab, und die meisten Ansätze alle 20 Jahre und älter sind. Wenn du das Hauptprodukt betrachtest, Linux, so ist das 40 Jahre alt, der einzige Unterschied heute: Es ist kostenlos nochmal programmiert worden. Man erkennt es am deutlichsten an VI, der dort immer noch der Editor der Wahl ist (soweit man nicht EMACS einsetzt). Klar kann man sagen, daß die Software, die in den letzten 10 Jahren entstand, es einfach noch nicht bis zu unseren Ohren geschafft hat, und noch 10 Jahre weiter sich durchsetzen muss, aber es ging allen auf der Party so, das kann also kein Defizit einzelner Personen sein. Ich freue mich, dass manches, welches vor 10 Jahren schwerfällig ging, heute flüssig läuft, ob 3D-CAD, Egoshooter oder Videobearbeitung, aber das ist mehr der Hardware geschuldet als der Software. Aber was wirklich Neues was die Welt bewegt? Google war ein Meilenstein, und hat auch "under the hood" was zu bieten, der Suchalgorithmus ist wirklich verdammt clever und effektiv, ohne den wäre Google nicht möglich gewesen (und wegen ihm haben Altavista & Co verloren). Auch Navi-Kartensoftware möchte heute niemand mehr missen, wenn auch deren Grundprinzip traveling salesman wirklich steinalt ist. Aber sonst, neue Software? Fehlanzeige, höchstens noch Eclipse ist den Leuten eingefallen, aber das ist Entwicklungssoftware und sofort fiel jedem auf, dass die auch noch grottenschlecht ist - nur halt das einzige, was die Lücke nach Borland füllen konnte. Nein, iTunes ist keine neue Software, Musik abspielen ist uralt, und auch ein "2 Finger Touchpad" hat uns nicht vom Hocker reissen können. Alls was man heute benutzt, ob Browser, Textverarbeitung, Tabellenkalkulation, Mathcad, Schaltplanlayout, Mail, ist von der Erfindung her uralt. Man hat den Eindruck, als ob die ganze aktuelle Garde der Softwarenetwickler nur das was es schon lange gibt noch mal nachprogrammiert - unter erschwerten Bedingungen wie grottenlagmarschigen abgekapselten Java oder gar im Browser - aber die Ergebnisse leider nicht BESSER sind als damals, sondern meistens schlechter. Also mit Innovation is nicht viel, als sich mir RSA-Verschlüsselungsalgorithmen und LZW-Kompression angesehen habe, hab ich mir vor Genialität noch auf die Schenkel geklopft, aber heute? Der BSP-Baum von Doom war nett, aber 10 Jahre zuvor hatte man eigentlich schon schnelleren (aber aufwändigeren) Code. Und das sind jetzt Einzelalgorithmen, nicht mal ganze Software. Dafür 3-buchstabige Dampfplauderer an jeder Ecke.
MaWin schrieb: >> > > Softwareleute haben das Problem, dass ihre Aufgabenstellung >> > > (im Idealfall) vorher noch nie jemand gemacht hat. >> >> > Prust, an Überheblichkeit mangelt es dir nicht... > >> Warum? > > Weil wir gerade neulich auf einer Party laut darüber nachgedacht > haben, dass es in den letzten 10 Jahren eigentlich verdammt wenig > bedeutende neue Software gab, und die meisten Ansätze alle 20 Jahre > und älter sind. Alles klar. Du bist auf allen Fachgebieten intimer Kenner der Szene. > Wenn du das Hauptprodukt betrachtest, Linux, Linux würde ich keineswegs als DAS Hauptprodukt betrachten. Das ist ein Betriebssystem .... > so ist das 40 Jahre alt, ... und es gab in der Zwischenzeit eine Menge anderer Betriebssysteme mit durchaus interessanten Ansätzen von denen weder du noch ich je gehört haben. Und nein: Das Original heißt Unix > und noch 10 Jahre weiter sich durchsetzen muss, aber es ging allen > auf der Party so, das kann also kein Defizit einzelner Personen sein. Doch ist es. Oder bist du fit, was sich alles im Bereich KI getan hat? (Ich bin es nicht). Was ist mit Expertensystemen, Fuzzy Logik, Neuronale Netze. Ich arbeite im Bereich CAD/Computer Graphik. Jedes Jahr werden auf der Siggraph Verfahren und Neuerungen präsentiert, von denen du dein Lebtag lang nichts gehört hast und die du nur deswegen überhaupt zu Gesicht bekommst, weil der neueste Kinofilm von Pixar davon Gebrauch macht. > Auch Navi-Kartensoftware möchte heute niemand mehr missen, wenn auch > deren Grundprinzip traveling salesman wirklich steinalt ist. Navi-Kartensoftware hat mit travelling salesman nicht das Geringste zu tun. > ich mir vor Genialität noch auf die Schenkel geklopft, aber heute? Der > BSP-Baum von Doom war nett, aber 10 Jahre zuvor hatte man eigentlich > schon schnelleren (aber aufwändigeren) Code. Sorry, aber jetzt disqualifizierst du dich selbst. Bleib in deiner kleinen Welt und programmiere für dich hin. Aber übeerlass das Gebiet der Algorithmenforschung den Leuten, die sich auch dafür interessieren.
Karl heinz Buchegger schrieb: > Oder bist du fit, was sich alles im Bereich KI getan hat? (Ich bin es > nicht). Was ist mit Expertensystemen, Fuzzy Logik, Neuronale Netze. Gerade da hat sich rein gar nichts getan.
Andreas Schwarz schrieb: > Karl heinz Buchegger schrieb: >> Oder bist du fit, was sich alles im Bereich KI getan hat? (Ich bin es >> nicht). Was ist mit Expertensystemen, Fuzzy Logik, Neuronale Netze. > > Gerade da hat sich rein gar nichts getan. Naja, dafür aber immerhin bei den probabilistischen KI-Algorithmen. Da tut sich doch in den letzten 10-20 Jahren noch ein wenig was...
> Oder bist du fit, was sich alles im Bereich KI getan hat? (Ich bin es > nicht). Was ist mit Expertensystemen, Fuzzy Logik, Neuronale Netze. Jupp. Nichts. Neuronale Netze waren das letzte bahnbrechende, wer wie ich damals an den ersten Implementationen mitgearbeitet hat, war überrascht, wie ähnlich deren Reaktion zur menschlichen Reaktion und Lernverhalten war, aber seit dem (sind 1 EUR Jobber billiger als jeder maschinelle Mensch-Ersatz...) FuzzyLogic war Vaporware mit Werbebrimbramborium, ich kenne einige der Internas von den Dingern die dick Fuzzy draufschrieben. > Doch ist es. Na was für ein kluges Kerlchen du doch bist. Wow wie peinlich sollte dir das sein. "Alle doof ausser mir."
Neuronale Netze waren nicht bahnbrechend. Das was man sich davon erhofft hat, wie Menschen denkende und lernende Programme zu schaffen, hat sich als Hirngespinst erwiesen. Neuronale Netze haben viele sinnvolle Anwendungen, aber nur als eines von vielen Werkzeugen, nicht als das Wundermittel das man gerne gehabt hätte.
> Oder bist du fit, was sich alles im Bereich KI getan hat? (Ich bin es > nicht). Was hindert dich daran, die Papers zu lesen? Der Inhalt ist erstaunlich trivial.
Sory, aber was MaWin von sich gibt ist schlichtweg Ignorant! Neue Sprachen wie Java & c# machen durchaus heute Dinge erst möglich die man früher nur sehr umständlich und unsicher erreichen konnte (Runtime Type information, Reflection) Damit lassen sich erweiterbare Systeme nach dem Bauksatenprinzip erstellen, von denen man in den letzten 10 Jahren immer Gesprochen, die aber nicht wirklich handhabbar waren. Im übrigen ist eine der Grundprämissen von Agile prozessen, dass nur durch solche modernen Sprachen und moderne Tools Dinge wie Automatisierte Unittests und Refactoring praxistauglich sind. Sicher, extrem viele Dinge basieren auf Ideen von vor 20-40 Jahren, aber erst heute werden sie wirklich Einsatzfähig. Wenn Ihr einen Bereich wissen wollt, in dem sich in den letzten jahren extrem viel getan hat, dann schaut mal in Biometrieanwendungen, oder Videokompression, obwohl ja schon ALLES bekannt ist kommt auf einmal ne Firma wie Oovoo und überträgt Bilder in ner besseren Qualiät als die anderen. MP3, nein, das war nichts umwerfendes. Selbst so popelige Sachen wie USB haben uns ja nicht ne Menge neue Geräte beschert. Erinnert euch mal ehrlich, wie viel von unserer heutigen Technik vor 20 jahren noch als Science Fiction galt. Und wenn wir von Gerätesoftware für neue Produkte sprechen, da haben wir es fast immer mit ganz neuen Aufgaben zu tun, auch wenn ich vielleicht nicht noch mal einen Quicksort erfinden muss. Tom
Ja, der große Fortschritt von Java & Co hat zu Firmen wie Dynatrace gehührt, die den schludrigen Programmierern (sowohl der Sprache als auch der Applikation) zeigen was das Moster wirklich macht. Refactoring & Co für Java konnte schon VisualCafe anno '98. Davor gab's Turbopascal, auch in brauchbarer Qualität. Von LSIP und Co ganz zu schweigen. Der "Fortschritt" im Mainstream besteht zu 90% Marketing, 9% Bugfixes und 1% gradueller Verbesserung. "Besser" sind die Programme deshalb nicht, meistens nur aufgeblasen bis zur Unwartbarkeit.
Klar und die Produktivität von Assembler ist die gleiche wie die von C#/Java Klar ging früher auch schon fast alles, nur wie. Und LISP/Smalltalk hat es ja nie in den Mainstream geschafft. .net ist auf jeden Fall für den PC ein echter Quantensprung, was Produktivität und Möglichkeiten angeht. Tom
Wer hat hier von Assembler gesprochen? Wenn dir LISP nicht zusagt, kannst ja mal nach Erlang Ausschau halten. .net ist für Microsoft ein Quantensprung. Ob deshalb bessere Software geschrieben wird darf bezweifelt werden.
Thomas Burkhart schrieb: > MP3, nein, das war nichts umwerfendes. Sieh Dir mal die Umsätze an, die mit allem was mit MP3 zu tun hat pro Jahr erwirtschaftet werden. Und die Veränderungen, die es in der Musikindustrie gegeben hat, bzw. die immer noch andauern (zum Großteil weil die Industrie zu dumm war und erst sehr spät auf den bereits davon eilenden Zug aufgesprungen ist). Und das soll nichts Umwerfendes sein? Was ist denn bitte dann umwerfend? Der Beweis P != NP oder was?
@Mark Brandis: Sorry hatte vergessen dazuzuschreiben Ironie ON
> Klar und die Produktivität von Assembler ist die gleiche wie die von > C#/Java Leider haben wir da einen ganz üblen Vergleich zwischen C und Java und der sieht für Java sehr schlecht aus. Klar kann so was immer an den Leuten, den Umständen etc. liegen, auch auch unter Betrachtziehung jeglicher äusserer Effekte bleibt ein Minus für Java, das zum Guten Teil geschuldet ist dem reinziehen von Dingen die andere Leute geschrieben haben und die sich als fehlerhaft herausstellten, also GERADE die Wiederverwendbarkeit bremste. Java hat bis heute kein brauchbares Library-Konzept. > Sieh Dir mal die Umsätze an, die mit allem was mit MP3 zu tun Das hat der Thomas ironisch gemeint, und, obwohl recht, ist das Verfahren auch schon von 1982 (siehe Wikipedia), nur der Standard halt von 1995, aber damit auch weit vor den 10 Jahren von denen ich redete.
MaWin: Ähm, C# ist was anderes als C, aber das weißt Du doch hoffentlich. Und .net/C# haben ein sehr durchdachtes Librarykonzept, weit besser als Java.
> C# ist was anderes als C,
Hab ich davon geredet?
Offenkundig nein.
Könnte das einen Grund haben ?
Pfeif, nach oben schau, mit den Füssen wippen....
Oh Mann Thomas.
Ja, du hattest reines C nicht erwähnt, sondern nur
3 schlechtere Alternativen verglichen.
Daher wollte ich das mal einwerfen, damit die Relation
wieder stimmt.
Thomas Burkhart schrieb:
> @Mark Brandis: Sorry hatte vergessen dazuzuschreiben *Ironie ON*
Ironiedetektion: Fail. ;)
SCRUM, ISO9000 und Co. -> alles sinnlos! Nehmt beliebig viele unfähige Programmierer und lasst die nach dem besten/tollsten/schönsten Modell arbeiten. Es kommt trotzdem nur schlechte Software raus. Meine Erfahrung ist, ob eine Software gut oder schlecht wird, hängt einzig und allein nur davon ab, ob man gute Leute hat. Die schlimmsten Programmierer sind die, die sowas nur studiert haben, weil sie denken damit gute Jobchancen zu haben.
@MaWin: Ehrlich gesagt ist mir schleierhaft wieso Du C# als schlechte Alternative bezeichnest. Schon mal damit gearbeitet?
Na ja, C# hat politisch verloren, es war die Antwort von Microsoft auf Sun's Java. "wir machen die unliebsame Java-Konkurrenz platt". Und da hat sich Microsoft aus universitären Quellen was wirklich feines ausgesucht. C# hat fast alles besser als in C++ gemacht, und vieles besser als in Java, aber es war eben von falschen Anbieter, und abgeboten mit der falschen Marketingstrategie. Da hilft auch kein Mono. Und bei den Manifests und Deployment von Modulen verschiedener Versionen hat man sich grandios verhauen, ich befürchte, der Teil kam nicht vom Erfinder, sondern wurde von Laien bei Microsoft drangestrickt. DotNET ist ein komplettes Betriebssystem, das um Längen besser (na ja, zumindest sauberer) als DOS/ Windows/NT ist, aber es ist eben zu 100% inkompatibel, und da hat sich schon seit 40 Jahren gezeigt, dass inkompatibel eben nicht geht, der Kunde will seinen alten Kram nicht wegwerfen, er hat ihn teuer bezahlt. Ein Betriebssystem hat Applikationen ablaufen zu lassen, und das nicht nach politischen Entscheidungen ausgesucht, sondern im Prinzip alle Applikationen die ich (irgendwoher) habe. Ich erwarte von einem Betriebsystem das es meine DOS-Programme, meine UNIX-Progarmme, meine Windows, die X-Windows-Programme und vor allem: Meine Apple ][ Programme, meine Atari-Programme, meine Atari/GEM Programme ablaufen lässt (sie wie MAME meine alten Spiele laufen lässt), seamless wie es ein ordentliches Windowing System halt kann. Schon von der Philosophie her ist Microsoft da meilenwert von weg, die sperren meine DOS-Proramme und meine Win16 Programme und haben in Windows nun 4 verschiedene Betriebssysteme nebeneinander deren Programm nicht miteinander reden können außer über Thunks: (Win16 nicht mehr), Win32, Win64 und DotNET (und Posix, na, reden wir nicht drüber), da sperre ich - und zig-Millionen andere ebenso - mich eben gegen Vista&7.
Angehängte Dateien:
> Schon von der Philosophie her ist Microsoft da meilenwert > von weg, die sperren meine DOS-Proramme und meine Win16 > Programme .. da sperre ich - und zig-Millionen andere > ebenso - mich eben gegen Vista&7. Wer sperrt denn deine uralten Win16 Programme? Läuft doch sogar unter W7 noch, siehe Anhang Screeshot von 16-bit Exe MS-Fonteditor vom September 1994, gerade mal von einer alten Visual-C CD aufgerufen. Und erkläre bitte mal welchen Stellenwert im (fast) Jahre 2010 noch eine Textfenster basierte MS-DOS Application haben soll? Hängst du etwa noch am alten Word Perfect? :)
Also ich hab ja kein Win7 :-) Aber die Aussage war klar: http://forums.ni.com/ni/board/message?board.id=140&thread.id=26233 (das ist jetzt eine Sekundärquelle, wurde aber oft genug erwähnt). > Und erkläre bitte mal welchen Stellenwert im (fast) Jahre 2010 > noch eine Textfenster basierte MS-DOS Application haben soll? Also wenn ich ein DOS Textfenster-basiertes Programm habe (und ich habe welche, die ich nicht neu schreiben will, und teilweise auch gar nicht kann weil sie von anderen stsmmen) dann ist es Aufgabe eines Betriebssystem die laufen zu lassen, sonst ist es kein Betriebssystem (aka Programm-Ausführungs- Umgebung) sondern ein Programmausführungsverhinderer. Ich habe einige Berechnungsprogramme für Mechanisk und Chemie oder Chip-Programmer oder Bedienprogramme für immer noch funktionierende Telefonanlagen, wo es weder Nachfolger (kostenlos) gibt, noch das verbundene Gerät weggeschmissen werden soll, bloss weil Firma Microsoft heute mal aus politischen Gründen beschliesst "den Kram löschen wir". (Es geht ja nicht mal um neuschreiben, den Kram haben sdie ja, sie müssne ihn nur beilegen).
für sowas hat man einen alten rechner mit 3.1 daheim einen mit W95 und 2 mit W98
Ich wüsste nicht, warum Windows kein richtiges OS sein sollte, nur weil es keine "UNIX-Progarmme, X-Windows-Programme, Apple ][ Programme, Atari-Programme, Atari/GEM Programme" ausführt. Das hat es nie und war auch nie die Aufgabe. Das ist so, als würdest du dich beschweren, dass dein Auto kein Diesel, Autogas, Wasserstoff, Strom, ... tankt. Denn dann ist es ja kein richtiges Auto, wenn es das nicht tut.
Also Apple ][, Amiga und Atari Programme laufen, ebensow MAME, aber die Programme kommen eben nicht von Microsoft und sind nicht so seamless wie sie sein könnten. Microsoft hat ein "not invented here" Problem.
> Also ich hab ja kein Win7 :-) Wäre aber besser wenn man nicht wie der Blinde über die Farbe reden würde. > Aber die Aussage war klar: > http://forums.ni.com/ni/board/message?board.id=140... > (das ist jetzt eine Sekundärquelle, wurde aber oft genug erwähnt). Und ich soll jetzt aufgrund deiner Behauptung aufdröseln welche Probleme mir völlig ungekannte Leute sich in anderen Forem um die Ohren hauen? Nee, Danke! Schau dir den Screenshot an, ich habe ixtra gerade für dich nach einer alten Win16 Anwendung gesucht und die unter Windows 7 32-bit ausgeführt und die läuft prächtig. Ob die 64 bit Version noch 16-bit Software unterstützt weiß ich nicht, aber ich halte diesen alten Zopf auch nicht mehr für relevant für dieses OS. >> Und erkläre bitte mal welchen Stellenwert im (fast) Jahre 2010 >> noch eine Textfenster basierte MS-DOS Application haben soll? > Also wenn ich ein DOS Textfenster-basiertes Programm habe > (und ich habe welche, die ich nicht neu schreiben will, und > teilweise auch gar nicht kann weil sie von anderen stsmmen) > dann ist es Aufgabe eines Betriebssystem die laufen zu lassen, > sonst ist es kein Betriebssystem (aka Programm-Ausführungs- > Umgebung) sondern ein Programmausführungsverhinderer. Genau das wird auch gemacht, aber eben nicht ewig und drei Tage für immer und alle Zeit, sonst würden heute noch genügend Firmen Anspruch darauf erheben ihre CP/M Code Programme noch auf jeder Workstation ausführen zu können. Außerdem gibt es auch Virtuelle Umgebungen für sowa .. > Ich habe einige Berechnungsprogramme für Mechanisk und Chemie > oder Chip-Programmer oder Bedienprogramme für immer noch > funktionierende Telefonanlagen, wo es weder Nachfolger >(kostenlos) gibt, noch das verbundene Gerät weggeschmissen > werden soll, bloss weil Firma Microsoft heute mal aus politischen > Gründen beschliesst "den Kram löschen wir". (Es geht ja nicht > mal um neuschreiben, den Kram haben sdie ja, sie müssne ihn > nur beilegen). Ich habe noch alte Germanium Transistoren die auf ganz tolle Einsätze warten und ebenso viele alte LS-TTL Chips die auf ganz bedeutungsvolle Einsätze in Elektronik-Gerätschaften warten und ich habe noch sooo viele alte bedrahtete Kondensatoren die von bösen, bösen SMD-Bauteilen verdrängt wurden und sich sehnlichst eine Aufgabe herbeiwünschen. Soll ich die etwa alle wegschmeißen, bloß weil ich die pöse Industrie aus reinen politischen Gründen mir jetzt so viele kleine SMD-Käferchen auf den Schreibtisch geschmissen hat? :-))
MaWin (Gast) wrote: > Ich habe einige Berechnungsprogramme für Mechanisk und Chemie > oder Chip-Programmer oder Bedienprogramme für immer noch > funktionierende Telefonanlagen, Telefonanlagen spielen können heute doch selbst die dümmsten Router besser als das alte Gewirsch aus der grauen MS DOS-Zeit, die in den Anfängen noch nicht mal ISDN kannte. Alte DOS Programme für Mechanik und Chemie? MaWin aus der Lernphase bist du doch schon längst draußen, die brauchst du doch gar nicht mehr. Gib deinem Herzen einen Stoß und mir das zu. :)
Julia Dorfmeister schrieb:
> Mich würden mal eure Meinungen zu dem Thema interessieren.
Und, jetzt schlauer?
Das ist doch bestimmt etwa das, was du hören wolltest, gell?
Klaus Wachtler schrieb:
> Das ist doch bestimmt etwa das, was du hören wolltest, gell?
Wieso auch nicht - man muss sich nur noch vorstellen, dass alle
Diskutanten zusammen ein Team bilden und dann pruefen, ob ein Vorgehen
nach SCRUM die Diskussion gerettet haette...
Zum Thema zurück. Ich habe grösseren Projekten mit und ohne SCRUM geleitet oder mitgearbeitet. Ich finde das Modell eigentlich ganz gut. Aus Modellsicht scheitern Projekte eher weniger am falschen Modell sondern eher am falsch gelebten Modell. Das ist aber nicht nur bei SCRUM so. Entscheidend ist weniger die Fähigkeiten der Mitarbeitern, sondern deren Motivation sich in gewissen Schranken zu bewegen. Und diese Schranken stellt ein Vorgehensmodell auf.
Remmy schrieb: > Zum Thema zurück. Ich habe grösseren Projekten mit und ohne SCRUM > > geleitet oder mitgearbeitet. Wir haben das bei uns erfolgreich eingeführt. War ein harter Weg, einige Möchtegernprogrammierer, hauptsächlich männlichen Geschlechts, mussten sich arg umstellen, dann war der Kuchen gebacken. Heute sind wir produktiver denn jeh!
Thread beobachten
Seitenaufteilung abschalten